Thanks for checking it. I confirmed that Firefox ESR (15.13) behaves the same way, as you confirmed. That's definitely not what I expected. My bad.
I looked for a specific bug in Mozilla's Bugzilla. It seems there isn't one for this, however, there are some bugs related to non-special schemes like "non-spec:" in the Interop 2024 meta bug. (Go https://bugzilla.mozilla.org/show_bug.cgi?id=1876105 > Details > tree) Given that, I've updated the platform status for Firefox from "Shipped" to "Positive". The previous I2S also had "Firefox: Positive", which I might have misinterpreted as "Shipped". Sorry about the lack of confirmation. Regarding Chrome, the flag is not yet enabled even in Canary. Thus, you need the command line argument, `--enable-features=StandardCompliantNonSpecialSchemeURLParsing`, to enable the flag in Chrome at this point. On Thu, Aug 15, 2024 at 5:46 PM Merih Akar <meriha...@gmail.com> wrote: > 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> > . > > -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFpjS_3EiksMcpbSsk8ZAz%3DiM7JAvc4fTSoGOLWBh7LYjeyu4g%40mail.gmail.com.
