Excellent, thank you! LGTM3, so excited to see this roll out. On Tue, Aug 20, 2024 at 1:03 PM Hayato Ito <hay...@chromium.org> wrote:
> Thanks! That makes sense too. I'm adding those schemes to the CL > <https://chromium-review.googlesource.com/c/chromium/src/+/5790445>. > > On Tue, Aug 20, 2024 at 11:31 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> 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 >>> >> > > -- > 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_RTTXpb3N1XNkBxRSNSjFn38YWzXOm1QZfOt_cY3SWNQ%40mail.gmail.com.
