Bug 215236

Created attachment 406115 [details] Patch

Comment on attachment 406115 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=406115&action=review > Source/WebCore/ChangeLog:10 > + This patch removes window.styleMedia, defined in early CSSOM View Module draft [1], > + that was later standardized as window.matchMedia. We are safe to remove StyleMedia > + since it isn't implemented by Firefox nor documented for web developers. This kind of removal inherently involves some risk. - Sometimes we find that non-web content, like say, certain old iOS apps, depends on something like this. Such content is often made by people who don’t know much about web technology. - Other times, we find that there are obscure corporate "Safari-only" websites that use some feature we assumed no one could have possibly used. I definitely would like to see this removed; is there some way we can quickly investigate, mitigate, or rule out those risks? Searching for the string styleMedia, I found a few things in the first couple pages of results: https://developer.apple.com/documentation/webkitjs/stylemedia - still in Apple documentation https://webplatform.github.io/docs/dom/Window/styleMedia/ - documented with no context https://stackoverflow.com/questions/49328382/browser-detection-in-reactjs - used as a way to tell the non-Chromium Edge apart from IE

(In reply to Darin Adler from comment #2) > Searching for the string styleMedia, I found a few things in the first > couple pages of results: This matches my findings. I've searched for "matchMedium" on GitHub, and there are a lot of code using it conditionally via a polyfill: https://github.com/paulirish/matchMedia.js/blob/3508a0aed9a4fad326b69af6fcf6a0da52d84984/matchMedia.js#L7. I've also found an answer on Stack Overflow (https://stackoverflow.com/a/57318118/6686844) that uses `styleMedia.type` to detect current @media type. > I definitely would like to see this removed; is there some way we can > quickly investigate, mitigate, or rule out those risks? Blink has feature counters: https://www.chromestatus.com/metrics/feature/timeline/popularity. Features with less than 0.10% page loads may be removed. To measure potential breakage, due to conditional usage, window.styleMedia should be made a [MasqueradesAsUndefined] object, while tracking matchMedium() calls. Does WebKit have similar API/stats?

(In reply to Alexey Shvayka from comment #3) > Blink has feature counters: > https://www.chromestatus.com/metrics/feature/timeline/popularity. Features > with less than 0.10% page loads may be removed. According to Google stats (https://www.chromestatus.com/metrics/feature/timeline/popularity/606), `window.styleMedia` usage is as high as 2.6%, while `styleMedia.matchMedium()` accounts for only 0.02% page loads, which makes sense given polyfill code. However, `styleMedia.type` is around 0.2%, as there is no other API for acquiring current @media, making StyleMedia non-removable for now.

(In reply to Alexey Shvayka from comment #4) > However, `styleMedia.type` is around 0.2%, as there is no other API for > acquiring current @media, making StyleMedia non-removable for now. !! So what should we do? Is there something we can do to gently truly push usage to zero?

(In reply to Darin Adler from comment #5) > So what should we do? Is there something we can do to gently truly push > usage to zero? I've commented a Stack Overflow on `styleMedia.type` answer. It would be great to remove StyleMedia from Apple docs, yet I can't find those in WebKit SVN. We could also add a console warning on deprecation, but it requires adding a JSStyleMediaCustom.cpp with a bit of code, and would be far less visible than a message in Chrome DevTools.

(In reply to Alexey Shvayka from comment #6) > I've commented a Stack Overflow on `styleMedia.type` answer. It would be > great to remove StyleMedia from Apple docs, yet I can't find those in WebKit > SVN. That’s right. Apple creates documentation for web technology, but it’s not directly part of the WebKit project. Might want to ask some of the other Apple contributors for how we work to create that documentation. We may come up with a better way to tie in the WebKit project to that effort. > We could also add a console warning on deprecation, but it requires adding a > JSStyleMediaCustom.cpp with a bit of code, and would be far less visible > than a message in Chrome DevTools. Yes, since the motivation here in part is to simplify the project it’s frustrating that it’s extra work to do that. I don’t know exactly what you’re referring to when you are implying here that "a message in Chrome DevTools" is highly visible and we don’t have a similarly visible alternative. I’d like to know more about that. Is it because more people use the Chrome developer tools than the WebKit-provided tools? Or is there some other factor that we could address?

(In reply to Darin Adler from comment #7) > I don’t know exactly what you’re referring to when you are implying here > that "a message in Chrome DevTools" is highly visible and we don’t have a > similarly visible alternative. I’d like to know more about that. Is it > because more people use the Chrome developer tools than the WebKit-provided > tools? Or is there some other factor that we could address? Yes, I was referring to popularity of Chrome developer tools. On a positive side, there are quite a few methods on Document and DOMWindow we can safely remove, as did Blink team.

Reopening to attach new patch.

Created attachment 406414 [details] Patch

Created attachment 406448 [details] Patch Add [NotEnumerable] IDL attribute.

Comment on attachment 406448 [details] Patch The new patch is a safe simplification: it removes 0.02% used window.styleMedia.matchMedium() while supporting window.styleMedia.type usage, even unconditional. Also, it introduces console warnings w/o adding new file.

This looks OK but we should hold off on landing for a couple of weeks until Apple cuts a branch.

<rdar://problem/67013066>

Pull request: https://github.com/WebKit/WebKit/pull/3049

Committed 253168@main (2d61c2bd67fb): <https://commits.webkit.org/253168@main> Reviewed commits have been landed. Closing PR #3049 and removing active labels.

Have we spoken to anyone on the Chrome side about this? It would be good to push them to also drop support if that's what we're doing (but I expect we'll get pushback from them about the [[IsHTMLDDA]] like [MasqueradesAsUndefined] extended attribute), and if we believe we can't actually remove it (as this suggests) then we should move to re-add it to the spec.