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) <
> 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>
> .
>

-- 
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/CAM0wra9m1qFkKLjKPu3B-fQMtvf0acXo3YGhZTWGeQcAgh-MVg%40mail.gmail.com.

Reply via email to