-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Labels
clarification
Standard could be clearer
interop
Implementations are not interoperable with each other
topic: custom protocols
Comments
This was referenced Sep 14, 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).
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? |
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
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.The text was updated successfully, but these errors were encountered: