Intent to Deprecate and Remove: Window.offscreenBuffering

1,681 views
Skip to first unread message

Philip Jägenstedt

unread,
Nov 28, 2014, 5:31:21 PM11/28/14
to blink-dev

Primary eng (and PM) emails

phi...@opera.com


Summary

Remove the readonly attribute boolean offscreenBuffering from Window.


Motivation

It's always true and does nothing at all. It can't be standardized without evidence that it's required for compatibility, and it likely isn't.


Compatibility Risk

This and a number of other Window attributes were added to KHTML in October 2000 with the commit message "fixes for www.php.net. looks pretty cool now :)":

https://projects.kde.org/projects/kde/kdelibs/repository/revisions/1743a834


However, I can't find offscreenBuffering actually used on www.php.net at the time:

I've found that the data from httparchive crawls can be downloaded:

Downloading and unpacking that crawl results in 216489 .har files, each a bundle of resources for a single page view.

60 .har files contain the string "offscreenBuffering", and going through them none seem like they could break stuff:

34 are in lists of global attributes for filtering, like http://wpg.blueconic.com/frontend/static/javascript/blueconic/blueconic.min.js

20 unconditionally set window.offscreenBuffering to true, like http://www.fc-moto.de/

2 check if window.offscreenBuffering != undefined and then sets it to true/false:

2 were false positives like http://www.sbu.gov.ua/sbu/js/menu.js

2 were in browser detection on www.micropayment.ch and www.micropayment.de that boils down to:
var ie=document.all?1:0;
var mac=(navigator.userAgent.indexOf("Mac")>-1)?1:0;
var ieReal=(ie&&(!mac)&&(typeof(window.offscreenBuffering)!='undefined'))?1:0;

Browser detection is the main thing that offscreenBuffering could break, but in this single example I found it's unreachable because document.all looks undefined when tested like this, precisely because this kind of code.

Alternative implementation suggestion for web developers

No change required.


Usage information from UseCounter

https://www.chromestatus.com/metrics/feature/timeline/popularity/356


That's around ~0.18%, far above what we would usually try removing.


Being an enumerable global property, I suspect that most hits are not deliberate. In the absence of the httparchive data, making it not enumerable would have been a way to verify that.

Entry on chromestatus.com, crbug.com, or MDN

http://msdn.microsoft.com/en-us/library/ie/ms534198(v=vs.85).aspx


Requesting approval to remove too?

Yes.

Philip Rogers

unread,
Dec 1, 2014, 5:10:23 PM12/1/14
to Philip Jägenstedt, blink-dev
I searched around our code as well and couldn't find any real users.

LGTM.

TAMURA, Kent

unread,
Dec 2, 2014, 4:47:04 AM12/2/14
to Philip Rogers, Philip Jägenstedt, blink-dev
Basically LGTM.

> That's around ~0.18%, far above what we would usually try removing.

It's high. I recommend to remove this just after branch so that we can have enough time to find serious issues.
--
TAMURA Kent
Software Engineer, Google


Philip Jägenstedt

unread,
Dec 2, 2014, 4:50:47 AM12/2/14
to TAMURA, Kent, Philip Rogers, blink-dev
On Tue, Dec 2, 2014 at 10:46 AM, TAMURA, Kent <tk...@chromium.org> wrote:
>
> Basically LGTM.
>
> > That's around ~0.18%, far above what we would usually try removing.
>
> It's high. I recommend to remove this just after branch so that we can have enough time to find serious issues.

Good idea, I'll do the removal in mid-January assuming this thread
gets another LGTM.

Philip

Chris Harrelson

unread,
Dec 2, 2014, 2:13:44 PM12/2/14
to Philip Jägenstedt, TAMURA, Kent, Philip Rogers, blink-dev
Since this attribute is not getting in the way, how about we first make it not enumerable, and see if usage drops? 0.18% is a lot.


To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Philip Jägenstedt

unread,
Dec 2, 2014, 4:30:26 PM12/2/14
to Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
OK, let's try that, if nothing else it will give us an idea of how much "noise" enumeration contributes.

Philip

Philip Jägenstedt

unread,
Mar 20, 2015, 3:22:56 AM3/20/15
to Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
As suspected, enumeration was a big contributor, at the counter is now dropping:

Based on counters that have been removed entirely in previous releases, it looks like it will take long time to settle:

I'll wait a bit longer before poking at offscreenBuffering, but since enumeration seems to contribute at least 0.1% on window attributes, I'd also like to make the following non-standard attributes on window not enumerable:

clientInformation
defaultStatus
defaultstatus
orientation
screenLeft
screenTop
styleMedia
webkitURL
WebKitAnimationEvent
WebKitMutationObserver
WebKitTransitionEvent

Does that seem OK? It's not entirely without risk, so if there are any of these that we think should stay long-term (and be standardized) we shouldn't mess with them.

Philip

Chris Harrelson

unread,
Apr 1, 2015, 8:51:28 PM4/1/15
to Philip Jägenstedt, TAMURA, Kent, Philip Rogers, blink-dev

Do any of them have sort of high use or no standard alternative? If so...

PhistucK

unread,
Apr 2, 2015, 12:44:34 AM4/2/15
to Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev

On Fri, Mar 20, 2015 at 10:22 AM, Philip Jägenstedt <phi...@opera.com> wrote:
orientation

​I imagine this one is not uncommon​.



☆PhistucK

Philip Jägenstedt

unread,
Apr 2, 2015, 6:25:11 AM4/2/15
to PhistucK, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Yes, perhaps it would be wise to deal with these on a case-by-case
basis. The one of immediate interest is styleMedia, since the
difference is usage between window.styleMedia and the StyleMedia
members could be due to enumeration:
https://www.chromestatus.com/metrics/feature/timeline/popularity/606
https://www.chromestatus.com/metrics/feature/timeline/popularity/607
https://www.chromestatus.com/metrics/feature/timeline/popularity/608

I will simply deal with these issues individually when it looks like
it could be blocking deprecation/removal.

Philip

Joe Medley

unread,
Apr 17, 2015, 3:49:34 PM4/17/15
to Philip Jägenstedt, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Did this get removed? If so, which milestone?

Joe Medley | Technical Writer | jme...@google.com | 816-678-7195

Philip Jägenstedt

unread,
Apr 17, 2015, 4:41:03 PM4/17/15
to Joe Medley, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
It hasn't been removed (or deprecated) yet. I'm still waiting to see how far https://www.chromestatus.com/metrics/feature/timeline/popularity/356 will drop in response to making it non-enumerable.

PhistucK

unread,
Oct 4, 2019, 10:01:53 AM10/4/19
to Philip Jägenstedt, Joe Medley, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
(Fast forward four years)
The top four sites on that page are actually seemingly defunct (what are they even doing in the HTTP archive? Are they skewing other results?), but the numbers are still high. Are there better tools today to find out whether this is actually being used?

☆PhistucK

Philip Jägenstedt

unread,
Oct 7, 2019, 5:50:52 AM10/7/19
to PhistucK, Philip Jägenstedt, Joe Medley, Chris Harrelson, TAMURA, Kent, Philip Rogers, blink-dev
Manual analysis of httparchive results is still the best bet for this I think. I thought it was pretty low risk to try removing this in 2014 and I doubt a lot of new content has begun using it since then. But it'd still require a new round of compat analysis since so much time has passed.

If anyone is interested I'd be happy to help out with how to slice the data.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_KrN82TY2d%2BAaM%3DeEF1JdkgGwEfRTkTSby5oqP8MHRv0Q%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages