LGTM1.
I think there is a small compat risk here, but in my opinion it's mitigated
by the movement toward interop, i.e. the fact that Firefox and Safari have
been shipping this behavior for years.
I tried to do some searching along the lines of what Mike suggests. GitHub
wasn't very useful ("client.url" is not a unique-enough string), but some
cases on StackOverflow would prefer the Firefox/Safari behavior, e.g. this
one
<https://stackoverflow.com/questions/45309959/service-worker-offline-support-with-pushstate-and-client-side-routing>
.
I feel that as long as the team stays vigilant about triaging incoming bugs
to watch out for breakage, and uses Finch to flip this off if such breakage
happens, we should feel comfortable pushing forward with this sort of bug
fix.
On Thursday, February 13, 2025 at 10:25:20 AM UTC+9 Mike Taylor wrote:
On 2/12/25 4:43 PM, 'Dave Risney' via blink-dev wrote:
Contact emails
[email protected], [email protected]
Explainer
None
Specification
https://www.w3.org/TR/service-workers/#client-url
Summary
Modify the service worker Client.url property to ignore document URL
changes via history.pushState() and other similar history APIs. The
Client.url property is intended to be the creation URL of the HTML document
which ignores such changes.
Blink component
Blink>ServiceWorker
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22>
TAG review
None: this is a bug fix change to an existing API surface area.
TAG review status
Not applicable
Risks
Interoperability and Compatibility
The service worker spec says that the Client.url property should be the
creation URL of the document which ignores changes made via
history.pushState and similar, rather than the URL which includes such
changes. Firefox and Safari match the standard. Chromium currently uses the
document URL. Changing Chromium behavior to match the standard could have
compatibility issues for existing web content that expects to see the
existing Chromium behavior of history.pushState API changes applying to the
Client.url property.
Can you help us estimate the compatibility risk here? One way might be to
find sites or apps (maybe via GitHub? HTTP Archive?) that are working
around this difference, so we can get a sense of what code paths might or
might not be affected.
*Gecko*: Shipped/Shipping (https://results.web-platform-
tests.org/results/service-workers/service-worker/
clients-matchall-client-types.https.html?label=experimental&
label=master&aligned&q=service-workers%2Fservice-worker%2Fclients-matchall-
client-types.https)
*WebKit*: Shipped/Shipping (https://results.web-platform-
tests.org/results/service-workers/service-worker/
clients-matchall-client-types.https.html?label=experimental&
label=master&aligned&q=service-workers%2Fservice-worker%2Fclients-matchall-
client-types.https)
*Web developers*: Positive (https://issues.chromium.org/issues/41405003)
Web developers have noticed and had to deal with this bug: *
https://github.com/w3c/ServiceWorker/issues/1515 *
https://issues.chromium.org/issues/41405003
*Other signals*:
WebView application risks
*Does this intent deprecate or change behavior of existing APIs, such that
it has potentially high risk for Android WebView-based applications?*
None
Debuggability
None
Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, ChromeOS, 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
This Web Platform test below validates aspects of the service worker Client
API. Currently Chromium is failing this test because the Client.url is the
document's URL when it should be the creation URL which ignores document
URL changes via the history API. https://results.web-platform-
tests.org/results/service-workers/service-worker/
clients-matchall-client-types.https.html?label=experimental&
label=master&aligned&q=service-workers%2Fservice-worker%2Fclients-matchall-
client-types.https
FWIW, it takes some digging to understand how this matchAll test failure is
realted to Client.url. Do we plan to add a more explicit test that reads
client.url after pushState() and asserts something useful?
Flag name on about://flags
None
Finch feature name
ServiceWorkerClientUrlIsCreationUrl
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/41337436
Estimated milestones
Shipping on desktop
135
Shipping on Android
135
Shipping on WebView
135
Anticipated spec changes
*Open questions about a feature may be a source of future web compat or
interop issues. Please list open issues (e.g. links to known github issues
in the project for the feature specification) whose resolution may
introduce web compat/interop risk (e.g., changing to naming or structure of
the API in a non-backward-compatible way).*
None
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/4996996949344256?gate=6527947635425280
--
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 [email protected].
To view this discussion visit https://groups.google.com/a/
chromium.org/d/msgid/blink-dev/SA6PR00MB235659A2F02466574F2E6
5478BFC2%40SA6PR00MB2356.namprd00.prod.outlook.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/SA6PR00MB235659A2F02466574F2E65478BFC2%40SA6PR00MB2356.namprd00.prod.outlook.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 [email protected].
To view this discussion visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bf726b47-0c10-4294-8dfc-354cdb58d1d4n%40chromium.org.
