-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
navigator.registerProtocolHandler specification divergent from both implementations #3377
Comments
Heh, @mgiuca just noted this over in whatwg/url#369 this morning. I guess it's good to have a tracking issue here too. Looking forward to the solution. |
There is an in-progress change that would align Chrome more closely with the current standard that likely won't land (at least in its current form) due to potential for breaking existing usage: https://crrev.com/c/835908 |
Interesting. I was planning to file this exact issue as a follow-up to whatwg/url#369. In my opinion, the current implementation (in both Chrome and Firefox) is correct, and the spec needs to be updated. See my recommendation in the URL spec bug. Instead of updating HTML, I would prefer to update the URL spec to specify "default encode set" properly, and then HTML will automatically be correct. |
See also #481. Might be nice to tackle that too when fixing this. |
Chromium issue tracker which includes some preliminary interop information from Firefox (Gecko/Necko?) and Blink: https://crbug.com/795919 If there are other extant implementations of this API I am unaware of them, so please enlighten me :) |
<a href>test</a>
<script>
result = []
for (i = 1; i < 0x82; i++) { // start at 1 for Firefox, see below
result.push(String.fromCharCode(i));
}
document.querySelector("a").href = "web-cat:begin" + result.join("") + "end";
</script> Firefox
Chrome
Analysis:
I have no idea how to create automated tests for this. Thoughts? I suspect I'll just create manual tests for now, which might be tricky enough. |
For automated tests, would it be possible to navigate to a protocol handler page that postMessages to the parent on success? (You'd you'd get a network error on failure, which would probably require waiting for a timeout...) |
I'm not sure how you'd register the scheme, but that seems like a possible setup for the manual test. |
Oh, right, this requires user confirmation. Probably that's a reasonable thing to ask for support from the WPT infra folks on. I bet most browsers already have a command line flag that allows such prompts to auto-confirm, for their own tests. |
This makes things a bit more explicit and aligns what was "escaped version" with implementations. Corresponding URL Standard PR: ... Tests: ... Closes #3377.
I had not yet realized that the above set I recommended is identical to |
This makes things a bit more explicit and roughly aligns what was "escaped version" with implementations. Corresponding URL Standard PR: whatwg/url#513. Tests: web-platform-tests/wpt#23504. Closes #3377.
web-platform-tests/wpt#23504 now has detailed manual tests (unfortunately not all run in Chrome due to custom schemes not working with service workers, but enough do). The results are similar to what I described above, but I'll summarize for clarity. The failures in Firefox are:
The failures in Chrome are:
Firefox would be happy to align with the proposed design. @bsittler @mgiuca Would Chrome? |
@ericlaw1979 perhaps you have thoughts on #3377 (comment)? |
@mfreed7 is this your responsibility at Google as well now? Could you weigh in on the above comment or find someone who can? |
@annevk this wouldn't be me, but perhaps @hayatoito could either comment or find the right person. |
It looks like the relevant directories in Chromium are: Based on the OWNERS files, I wonder if @benfredwells @dominickng @mgiuca @raymeskhoury would be able to review the suggestion in #3377 (comment)? |
@annevk :
Changing this to encode U+0020 as %20 SGTM. I can't see how that would break sites, since they have to decode all the other %-escapes, I don't see why a site would special-case not decoding %20 properly.
I don't understand this one. Why would you encode U+007F as %257F? (i.e., why not just encode it once like every other character)? Can you elaborate why you think that would be correct behaviour? |
@mgiuca the URL parser would have already encoded U+007F as |
Hi Anne, thanks for working on this! I'm not an expert in URL parsing, but after reading the proposed tests and spec changes, this looks good to me overall. Regarding U+007F, you are essentially saying that https://url.spec.whatwg.org/#concept-basic-url-parser will percent-encode some characters in various supersets of https://url.spec.whatwg.org/#c0-control-percent-encode-set (C0 controls and all code points greater than U+007E), right? (Incidentally, I noticed that there are two notes mentioning "greater than U+007F DELETE" or "higher than U+007F DELETE", maybe including U+007F was included later and not updated everywhere?) Here is a simple test with registerProtocolHandler which behaves differently in Firefox and Chrome:
Firefox's output "%1F%7F" sounds correct since IIRC, the parser will do:
Regarding U+0020, I don't have any strong opinion on this but as I see this is indeed what is expected from your proposal to use this new "component percent-encode set" which includes the "query percent-encode set" and so U+0020, so that test looks correct. Regarding service worker, Domenic mentioned elsewhere https://bugs.chromium.org/p/chromium/issues/detail?id=522370 ; I guess it's fine to keep them if it's just a bug in Chrome. Regarding automating tests from my understanding of chrome's implementation I believe the UI permission request, handler preference registration and conversion of the URL with custom scheme are all done on the chrome side (not blink), so I think we would need a full chrome brower running (like what is done with the ./wpt run) rather just a blink content shell (like what is done with python third_party/blink/tools/run_web_tests.py). So even if we could use testdriver to emulate user clicks and introduce a new API to register a protocol or auto-accept permission requests, I don't think that would exercise the code in chrome/common/custom_handlers/protocol_handler.cc anyway ; and Anne's manual tests are fine for WPT coverage of the spec. In Chrome, we will likely need to do a C++ ui test like what I'm doing in https://chromium-review.googlesource.com/c/chromium/src/+/2287304/25/extensions/browser/api/protocol_handler_interactive_uitest.cc in order to obtain an automated test. Finally, note that BroadcastChannel is not supported in WebKit (and probably not instrumental for your test) see https://bugs.webkit.org/show_bug.cgi?id=161472 ; just mentinoning it but this is probably not relevant given there is no plan to support registerProtocolHandler in WebKit. |
Here is a testcase to check percent escaping in https://url.spec.whatwg.org/#concept-basic-url-parser
Chrome does not properly handle escaping of 0+7F in https://url.spec.whatwg.org/#cannot-be-a-base-url-path-state and https://url.spec.whatwg.org/#fragment-state ; I investigated a bit and I'm able to fix this by modifying these two lines: https://source.chromium.org/chromium/chromium/src/+/master:url/url_canon_pathurl.cc;drc=19b1e5e4e1914b5b7464062ec300b817d2bac53d;l=35 |
Oh, I see, so we expect double-encoding of any reserved character, once as part of the basic URL parsing and then again to insert it into the parent URL. If Chrome does that in general, but just doesn't do it for U+007F as an unrelated issue, then I'm fine with that (and we can look at that as just part of Chrome's general minor lack of adherence to the spec). I think Chrome is generally fine with this change. |
OK, so the U+007F chromium bug is known, it's actually https://bugs.chromium.org/p/chromium/issues/detail?id=809852 ; I uploaded a CL with WPT tests. Regarding U+0020, the fix would be straightforward, just pass use_plus=false here: https://source.chromium.org/chromium/chromium/src/+/master:chrome/common/custom_handlers/protocol_handler.cc;drc=e8e7b4663189369a0ec9117c7fac954fdbe219d1;l=101 After these changes, I verified that Anne's manual tests without service worker pass in Chrome. I don't know if I can speak for Chromium dev (I will have to send a formal intent-to for these two changes above) but at least I can say Igalia is interested in fixing these two bugs. |
This makes things a bit more explicit and roughly aligns what was "escaped version" with implementations. Corresponding URL Standard PR: whatwg/url#513. Tests: web-platform-tests/wpt#23504. Closes #3377.
Currently, URLs calculated by protocol handlers escape spaces as "+". This CL changes this to use "%20" instead, aligning with Firefox and the specification. For details, read the following links: https://chromestatus.com/feature/5678518908223488 https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/osabCTBhDSs https://bugs.chromium.org/p/chromium/issues/detail?id=795919 https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers whatwg/html#3377 Bug: 1110842 Change-Id: I31e2250c56d3c4654d5a8655ead953af33b5fb5c Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2324126 Reviewed-by: Dominick Ng <dominickn@chromium.org> Commit-Queue: Frédéric Wang <fwang@igalia.com> Cr-Commit-Position: refs/heads/master@{#799541}
This makes things a bit more explicit and roughly aligns what was "escaped version" with implementations. Corresponding URL Standard PR: whatwg/url#513. Tests: web-platform-tests/wpt#23504. Closes whatwg#3377.
For navigator.registerProtocolHandler the standard says:
However this does not seem to agree with either of the extant implementations, both of which
%
-escape%
itself in the resulting URL (to%25
) and also vary in other particulars (for instance, it seems+
is escaped, presumably to avoid its conversion to space in handlers expecting query strings.)The text was updated successfully, but these errors were encountered: