Skip to content

Update registerProtocolHandler() and unregisterProtocolHandler() #3043

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
annevk opened this issue Sep 14, 2017 · 3 comments
Open

Update registerProtocolHandler() and unregisterProtocolHandler() #3043

annevk opened this issue Sep 14, 2017 · 3 comments
Assignees
Labels
clarification Standard could be clearer interop Implementations are not interoperable with each other topic: custom protocols

Comments

@annevk
Copy link
Member

annevk commented Sep 14, 2017

Now #630 is addressed there's a bunch of prose here that could be redone. And we need to figure out if Edge and Safari are willing to implement this. In addition we need to get at least one more browser to adopt unregisterProtocolHandler() as currently it's Chrome-only.

@annevk annevk added clarification Standard could be clearer interop Implementations are not interoperable with each other labels Sep 14, 2017
@annevk annevk self-assigned this Sep 14, 2017
@annevk
Copy link
Member Author

annevk commented Sep 15, 2017

So a protocol handler registry would be a map of protocols to a list of URLs? Can anyone poke a hole in that? I'm somewhat surprised we haven't defined this yet...

annevk added a commit that referenced this issue May 7, 2020
Less ambitious, but still solves a couple problems and makes room for future cleanup:

* Closes #3828 and closes #3830 by defining scheme validation fully.
* Also defines validation for unregisterProtocolHandler(), which was poorly defined but in its single implementation matches that of registerProtocolHandler().
* Removes the note about inline usage and gopher as it's unclear how valid that was to begin with and we're slowly moving towards only opening these top-level anyway.

Ideally a future cleanup defines an internal model for storing handlers and where that is (and is not) consulted. See #3043.

Tests: web-platform-tests/wpt#23458 (combined with the tests already there).
annevk added a commit that referenced this issue May 9, 2020
Less ambitious, but still solves a couple problems and makes room for future cleanup:

* Closes #3828 and closes #3830 by defining scheme validation fully.
* Also defines validation for unregisterProtocolHandler(), which was poorly defined but in its single implementation matches that of registerProtocolHandler().
* Removes the note about inline usage and gopher as it's unclear how valid that was to begin with and we're slowly moving towards only opening these top-level anyway.

Ideally a future cleanup defines an internal model for storing handlers and where that is (and is not) consulted. See #3043.

Tests: web-platform-tests/wpt#23458 (combined with the tests already there).
@domenic
Copy link
Member

domenic commented Aug 5, 2020

This might be worth closing at this point, although perhaps you still want to create a rigorous map-like structure? And I guess refer to that from the navigate algorithm?

@annevk
Copy link
Member Author

annevk commented Aug 6, 2020

Yeah, I think that would be ideal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clarification Standard could be clearer interop Implementations are not interoperable with each other topic: custom protocols
Development

Successfully merging a pull request may close this issue.

2 participants