-
Notifications
You must be signed in to change notification settings - Fork 27
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
Carryover evaluation: URL #424
Comments
@lucacasonato thanks for filing this! As I suspect you've seen, URL is part of https://wpt.fyi/interop-2023. Is this a proposal to carry forward that exactly as-is into Interop 2024, or are you suggesting an expansion of scope? |
I'm suggesting to carry it forward because the progress made by Chrome and Firefox was rather limited so far this year. There is still very significant incompatibility, especially around non-special URL handling in Chrome. (this case |
If we wanted to change something to promote more progress in this area, we could consider only including tests that don't already pass in all three engines at the start of Interop 2024. Right now 84% looks "good" only because the majority of tests are for |
A list of bug reports in Chromium seems outdated. You can see a list of issues tracked in interop 2023 in Chromium here: As of Sep 19, there are 4 issues remaining (at least, we are aware of):
1 and 2 are about IDNA handling, which no one has started to work on yet. My rough estimation at present is
|
@hayatoito Thanks, I've updated the Chromium issue list. I agree that the impact of the non-special handling in Chromium currently is the largest incompatibility. I don't think we can meaningfully say "URL is interoperable" until this is fixed. |
I've added the carryover-evaluation label as this is about continuing/expanding an existing focus area. |
Just got another report about the non-standard protocol discrepancy on our issue tracker: denoland/deno#20733 |
@lucacasonato to make the proposal clear, are you suggesting adding any tests at all, or "just" continuing with the exact set of tests that are part of Interop 2023? |
Thank you @lucacasonato for filing this! In #565 I argued for inclusion of URL as well because of non-special URLs (as you mention) as well as improving IDNA support so end users can reach the same websites reliably. And also that if we were to add #525 as a focus area, it would be especially important to include URL due to URLPattern's fundamental dependency on URL. Furthermore, I suggested a slight expansion in terms of testing to account for some work I did this year on endpoints that invoke the URL parser with a non-UTF-8 encoding: |
Just for the record, the bugs in Chrome are: |
Description
The URL parsing algorithm in web browsers
Specification
https://url.spec.whatwg.org/
Open Issues
No response
Tests
https://wpt.fyi/results/url?label=master&label=experimental&aligned
Current Implementations
Standards Positions
N/A, URL has been widely shipped since the beginning of time :)
Browser bug reports
https://crbug.com/724018
https://crbug.com/1406728
https://crbug.com/1416006
https://crbug.com/1416013
https://bugzilla.mozilla.org/show_bug.cgi?id=1553105
https://bugzilla.mozilla.org/show_bug.cgi?id=1848511
https://bugzilla.mozilla.org/show_bug.cgi?id=1722328
Developer discussions
Confusion because URL parsers across Blink, Gecko, WebKit, Node, and Deno do not interop well. The root cause is nearly always parser bugs in Blink or Gecko: https://twitter.com/oleg008/status/1699087223751073883
Polls & Surveys
No response
Existing Usage
URL is very widely used - custom schemes are commonly used for links to native apps, or when dealing with developer tooling like databases. They may also become exceedingly more common with import maps.
Workarounds
There are no good workarounds - one can import
whatwg-url
, the URL reference implementation if they need perfectly spec compliant behaviour, but this only gets one so far. This breaks down when using browser built-in features that use URL parsing internally, like import maps.Accessibility Impact
None
Privacy Impact
None
Other
This has been ab interop problem in browsers for many many years, and except for WebKit, who fixed their parser a couple years ago and proved that a compliant parser is web compatible, no-one has invested the time to fix the shortcomings their browser.
The text was updated successfully, but these errors were encountered: