Excellent, thank you! Your updated section of the document states
> There have been several non-special schemes (like "isolated-app://") which are registered <https://source.chromium.org/chromium/chromium/src/+/main:chrome/common/chrome_content_client.cc;l=225;drc=0312be31243152b47aa6158749e28f61604b54ff> in the SchemeRegistry so that they are parsed if they were special scheme URLs. I believe this means that the following schemes: - isolated-app: - chrome-native: - chrome-search: - chrome-distiller: - android-app: - chrome-resource: - chrome-extension: - fuchsia-dir: will not match the URL Standard either. (Testing with --enable-features=StandardCompliantNonSpecialSchemeURLParsing on the live URL viewer <https://jsdom.github.io/whatwg-url/#url=Y2hyb21lLW5hdGl2ZTovL3g6MC9h&base=YWJvdXQ6Ymxhbms=> seems to confirm this.) In that case, please add those schemes to your CL <https://chromium-review.googlesource.com/c/chromium/src/+/5790445> as well. Then I am happy to approve! On Mon, Aug 19, 2024 at 4:30 PM Hayato Ito <hay...@chromium.org> wrote: > Thanks for the feedback! > > On Fri, Aug 9, 2024 at 5:19 PM Domenic Denicola <dome...@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? >> >> > Sounds good! I'm adding tests here: https://crrev.com/c/5790445. > I'll make sure to land this CL before enabling the flag. > > >> >> - 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. >> >> >> > Re the 2nd and the 3rd points, I've added a "Future Work > <https://docs.google.com/document/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/edit?pli=1&resourcekey=0-d1gP4X2sG7GPl9mlTeptIA&tab=t.0#heading=h.4685f6p8tio9>" > section to the document to capture what I have in mind and what should be > done next. Thanks for the suggestion! > I've also removed some outdated content from the document like "(TBD) > Remove the Scheme Registry". > > > > >> >> >> 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) < >>> yoavwe...@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+unsubscr...@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+unsubscr...@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> >>> . >>> >> > > -- > 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/CAM0wra-szMG0E4%3D%2BSoMysrbNEFgrVTpLLWkDyKnQaB485FNeHQ%40mail.gmail.com.
