Web-Facing Change PSA: navigator.storage no longer an EventTarget

[Chromestatus]

Contact emails

est...@chromium.org

Specification

https://storage.spec.whatwg.org

Summary

navigator.storage is no longer an EventTarget navigator.storage was made an EventTarget for the Storage Pressure Event, which never made it past the prototype phase: https://chromestatus.com/feature/5666274359115776 This dead code is being removed and as a result, navigator.storage will no longer extend EventTarget.

Blink component

Blink>Storage>Quota

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change is technically web-facing, but it brings Chromium in line with other browser vendors. It's very unlikely any site used the functionality because Chromium never fired an event at navigator.storage except in developer builds.

Gecko: No signal

WebKit: No signal

Web developers: No signals

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?

Yes

Flag name on chrome://flags

None

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	132
Shipping on Android	132

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/5132158480678912?gate=5665876618248192

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 10/30/24 7:54 PM, Chromestatus wrote:

Contact emails

est...@chromium.org

Specification

https://storage.spec.whatwg.org

Summary

navigator.storage is no longer an EventTarget navigator.storage was made an EventTarget for the Storage Pressure Event, which never made it past the prototype phase: https://chromestatus.com/feature/5666274359115776 This dead code is being removed and as a result, navigator.storage will no longer extend EventTarget.

Blink component

Blink>Storage>Quota

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This change is technically web-facing, but it brings Chromium in line with other browser vendors. It's very unlikely any site used the functionality because Chromium never fired an event at navigator.storage except in developer builds.

Bringing us in line with other browsers is good, but not necessarily a guarantee that things won't go wrong. Have we done any kind of research to determine that sites weren't attempting to use this?

At the very least, having the ability to kill-switch this with a flag would be advisable - right now this PSA suggests otherwise.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6722c71d.2b0a0220.230002.023f.GAE%40google.com.

[Evan Stade]

> having the ability to kill-switch this with a flag would be advisable

Is that possible? My understanding is that it is not. If it were, then it would have been gated behind the (never-exposed) flag to begin with.

> Have we done any kind of research to determine that sites weren't attempting to use this?

Do you mean attempt to use in its intended fashion, or attempt to use it for browser engine detection? For the former: I think it's impossible because it never even got to dev trial. For the latter, are there popular libraries out there we can look at? This one does not use it.

Googling for "navigator.storage.addeventlistener" turns up only the explainer for the Storage Pressure event. "navigator.storage instanceof EventTarget" turns up nothing.

-- Evan Stade

[Yoav Weiss (@Shopify)]

Thanks for sending this!

On Thu, Oct 31, 2024 at 3:31 AM Evan Stade <est...@chromium.org> wrote:

> having the ability to kill-switch this with a flag would be advisable

Is that possible? My understanding is that it is not. If it were, then it would have been gated behind the (never-exposed) flag to begin with.

I believe you're right and we don't currently have the means to put an IDL inheritance change behind a flag.

That's the reason we shipped this inheritance in the first place 4 years ago.

 

> Have we done any kind of research to determine that sites weren't attempting to use this?

Do you mean attempt to use in its intended fashion, or attempt to use it for browser engine detection? For the former: I think it's impossible because it never even got to dev trial. For the latter, are there popular libraries out there we can look at? This one does not use it.

Googling for "navigator.storage.addeventlistener" turns up only the explainer for the Storage Pressure event. "navigator.storage instanceof EventTarget" turns up nothing.

That's very promising. For extra confidence, you could query the HTTP archive for the above string (or "StorageManager instanceof EventTarget"). 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAO4XGS9Q-KEswN_A%3DSc-UUqVMSJb7SFz5COJoRLJRhGn1A68Fw%40mail.gmail.com.

[Evan Stade]

On Thu, Oct 31, 2024 at 1:33 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Thanks for sending this!

On Thu, Oct 31, 2024 at 3:31 AM Evan Stade <est...@chromium.org> wrote:

> having the ability to kill-switch this with a flag would be advisable

Is that possible? My understanding is that it is not. If it were, then it would have been gated behind the (never-exposed) flag to begin with.

I believe you're right and we don't currently have the means to put an IDL inheritance change behind a flag.

That's the reason we shipped this inheritance in the first place 4 years ago.

 

> Have we done any kind of research to determine that sites weren't attempting to use this?

Do you mean attempt to use in its intended fashion, or attempt to use it for browser engine detection? For the former: I think it's impossible because it never even got to dev trial. For the latter, are there popular libraries out there we can look at? This one does not use it.

Googling for "navigator.storage.addeventlistener" turns up only the explainer for the Storage Pressure event. "navigator.storage instanceof EventTarget" turns up nothing.

That's very promising. For extra confidence, you could query the HTTP archive for the above string (or "StorageManager instanceof EventTarget"). 

Thanks. I'm not sure if this is still possible to do. This doc suggests that crawling all response bodies is discouraged, and in practice, it seems to no longer be possible as the bodies are no longer in any table I can find. "Querying" now consists of adding scripts to the crawler that will take 30 days to return any data. (Would be happy if I am wrong about this.)

[Evan Stade]

On Thu, Oct 31, 2024 at 9:29 AM Evan Stade <est...@chromium.org> wrote:

On Thu, Oct 31, 2024 at 1:33 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

Thanks for sending this!

On Thu, Oct 31, 2024 at 3:31 AM Evan Stade <est...@chromium.org> wrote:

> having the ability to kill-switch this with a flag would be advisable

Is that possible? My understanding is that it is not. If it were, then it would have been gated behind the (never-exposed) flag to begin with.

I believe you're right and we don't currently have the means to put an IDL inheritance change behind a flag.

That's the reason we shipped this inheritance in the first place 4 years ago.

 

> Have we done any kind of research to determine that sites weren't attempting to use this?

Do you mean attempt to use in its intended fashion, or attempt to use it for browser engine detection? For the former: I think it's impossible because it never even got to dev trial. For the latter, are there popular libraries out there we can look at? This one does not use it.

Googling for "navigator.storage.addeventlistener" turns up only the explainer for the Storage Pressure event. "navigator.storage instanceof EventTarget" turns up nothing.

That's very promising. For extra confidence, you could query the HTTP archive for the above string (or "StorageManager instanceof EventTarget"). 

Thanks. I'm not sure if this is still possible to do. This doc suggests that crawling all response bodies is discouraged, and in practice, it seems to no longer be possible as the bodies are no longer in any table I can find. "Querying" now consists of adding scripts to the crawler that will take 30 days to return any data. (Would be happy if I am wrong about this.)

OK, hurray, I am wrong. With the help of the archivist I was able to find tables that still contain response_body and are reasonably responsive to queries, and there are 0 hits among the top 100k sites for 'navigator.storage instanceof', 'StorageManager instanceof', or 'navigator.storage.addEventListener' as of 2024/10/1

[Yoav Weiss (@Shopify)]

Amazing! Thanks for running these queries!!

Please keep a close eye for related bugs as this will reach stable, just to make sure we're on it if unexpected breakage occurs

[Mike Taylor]

+1, thanks Evan.