Hi, In our app we're using a custom protocol, and I'm trying to understand if this change would affect how we handle some URL schemes we use.
In the interoperability section you mentioned that firefox already supports non-special scheme URLs, however when I test right now the result in firefox is the same as old behavior, not like the example you shared as "after": [image: image (4).png] I tried to test the new behavior in chrome canary, but the result was the same there too, so is there any place where we can test parser changes to see if it breaks our code? Or is this change not visible to web authors? Thanks, -- merih On Friday, August 9, 2024 at 7:06:30 PM UTC+3 Chris Harrelson wrote: LGTM2 On Fri, Aug 9, 2024 at 1:19 AM Domenic Denicola <dom...@chromium.org> wrote: I'm very excited to see this work proceeding and am looking forward to being able to LGTM. A few requests before we get there: - From what I understand we still won't be spec-compliant for android:, drivefs:, steam:, chromeos-steam:, and materialized-view:. Can you add failing web platform tests for all of those cases, to ensure that we capture this non-compliance? - I don't understand the role of the scheme registry after we ship this change. What will it do? The doc says "(TBD) Remove the Scheme Registry. This can be yet another non-trivial project. This document does not cover this task." Are there still web-exposed behaviors between non-registered and registered schemes? Is there a danger that people will add more schemes to the registry and cause URL parsing to change? Or is this purely about code cleanup as after this change the scheme registry is a no-op? - In general it would be great to have a section of the doc covering future work, such as fixing those exceptional schemes, removing the scheme registry, and anything else that you have in mind. In particular I'm interested in which of these future work projects have compat impacts so we can know how web developers might see URL parsing change in the future. On Fri, Aug 9, 2024 at 4:28 PM Hayato Ito <hay...@chromium.org> wrote: I've added a new section, "Compatibility Risks <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA&tab=t.0#heading=h.kb3fb29h4kax>", to the doc, organizing the content more clearly. Thanks! On Fri, Aug 9, 2024 at 3:03 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote: Thanks for working on this!! On Thu, Aug 8, 2024 at 10:09 AM Hayato Ito <hay...@chromium.org> wrote: Contact emails hay...@chromium.org Explainer http://bit.ly/url-non-special Specification https://url.spec.whatwg.org/ <https://url.spec.whatwg.org/#url-parsing> Summary Support non-special scheme URLs. Previously, Chromium's URL parser didn't handle non-special scheme URLs properly. It treated these URLs as “opaque paths”, which didn’t align with the URL Standard. Now, Chromium’s URL parser correctly processes non-special URLs. Examples: Before: > const url = new URL("git://host/path"); > url.host "" > url.pathname "//host/path" > url.host = "newhost"; > url.host "" > const url = new URL("git://a b/path"); > url.pathname "//a b/path" After: > const url = new URL("git://host/path"); > url.host "host" > url.pathname "/path" > url.host = "newhost"; > url.host "newhost" > url.href "git://newhost/path" > const url = new URL("git://a b/path"); => throws Exception. // A space character is not allowed as a hostname. See http://bit.ly/url-non-special for more details. As part of our Interop 2024 efforts, this change delivers the following improvements: - Boosts WPT URL Score: 936 previously failing subtests in the WPT URL tests (link <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA&tab=t.0#heading=h.ji1rj1k19sgh>) now pass, raising the score from 87.0% to 94.7%. - Fixes code relying on incorrect URL behavior: 527 tests (link <https://docs.google.com/spreadsheets/d/1Pqw1iKXK_lxHj-kLIAeRFs-khFz-BPZDio1W7SgEVE4/edit?usp=sharing>) and related code in Chromium that depended on the previous behavior are now fixed or mitigated, including: - Web tests that relied on non-compliant non-special URL behavior (e.g. “javascript://a b” URL) - Non-special schemes used internally by Chromium code base, including ChromeOS (e.g. “steam:”, “materialized-view://”, “cros-apps://”) Blink component Internals>Network <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> TAG review Not applicable Risks Interoperability and Compatibility Since Safari and Firefox already support non-special scheme URLs, the likelihood of public websites breaking due to this change is likely low. See here <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA&tab=t.0> for a rough estimation of the non-special scheme URL usages. Any particular section in that doc that talks through or estimates the compat risk? Gecko: Shipped WebKit: Shipped Web developers: Generally seems positive. Some signals (from interop 2024 discussions <https://github.com/web-platform-tests/interop/issues/424>) are: - > 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 - > 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. Other potential risks and assessments: - Enterprise usage: It's difficult to predict how non-special URLs are used in the wild, especially by enterprise customers with in-house apps. While adding an Enterprise Policy was considered to mitigate risks, technical limitations make it difficult to support URLs. See http://bit.ly/url-non-special for more info. We'll disable the feature with Finch (StandardCompliantNonSpecialSchemeURLParsing flag) in case this causes serious issues. - Impacts on well-known non-special schemes: See here <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA&tab=t.0#heading=h.k3rirdjyomw6> for the impacts on “javascript://”, “data:”, and so on. - Impacts on dependent components: This change affects components relying on URL behavior, like Origin <https://url.spec.whatwg.org/#origin>. See the Security section below. Security In Chromium, GURL, KURL, and web-facing URL APIs share the common URL parser backends, which reside in //url. As a result, this web-facing change will also affect core components like url::Origin, kurl::SecurityOrigin. For detailed information on how url::Origin, kurl::SecurityOrigin, and web-facing url.origin are impacted, please refer to this CL’s description <https://chromium-review.googlesource.com/c/chromium/src/+/5309015>. TL;DR. This is a complex issue due to historical reasons. While most components remain unaffected, there are some nuances, particularly regarding the “Android WebView Hack”. We’ve preserved the current Origin behavior for Android WebView. WebView application risks Beyond the aforementioned "Android WebView Hack", there are no other changes specific to WebView. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes. Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? Yes (dashboard <https://wpt.fyi/results/url?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-url> ) Flag name StandardCompliantNonSpecialSchemeURLParsing Requires code in //chrome? False Tracking bug https://crbug.com/1416006 Estimated milestones M130 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5201116810182656 Links to previous Intent discussions Previous I2S <https://groups.google.com/a/chromium.org/g/blink-dev/c/wYuPrIQzDTA/m/uoL4bXR2BgAJ>. The previous I2S mail was sent last year but please consider this intent to ship as a new one. -- Hayato -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1_R%3D%2BHXYgTCuLD_WGR0foLKVnxAU9am1QbHyAZ%3D%2B3Ohw%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1_R%3D%2BHXYgTCuLD_WGR0foLKVnxAU9am1QbHyAZ%3D%2B3Ohw%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- Hayato -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1%3D48YmdprXVdy_3SWRqneFFcy6BRuaw_w%2BxvrjyAc2CA%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_1%3D48YmdprXVdy_3SWRqneFFcy6BRuaw_w%2BxvrjyAc2CA%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9m1qFkKLjKPu3B-fQMtvf0acXo3YGhZTWGeQcAgh-MVg%40mail.gmail.com <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra9m1qFkKLjKPu3B-fQMtvf0acXo3YGhZTWGeQcAgh-MVg%40mail.gmail.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f59ac362-dff5-4540-b668-db1e5557fc83n%40chromium.org.
