Should the lifetime of a Screen object be limited?

[michaelwasserman]

A question about the lifetime of Screen objects was raised recently:

Looks like this takes the extra step of exposing this to workers, whereas the original Screen object was not. This raises an interesting question (and I believe it's one that we'll have to answer if we move to partial interfaces). The current Screen implementation returns 0's once the LocalFrame for the associated Screen object is gone. Should ScreenEnumerationScreen be doing that too, somehow?

We should consider this further, but my initial inclination would be to allow the Screen to exist beyond the lifetime of any LocalFrame. One requirement of this interface is providing screen information to open a window when a worker doesn't have any windows open (perhaps triggered by a notification). That scenario might be more difficult if the Screen lifetime is linked to that of a LocalFrame. Perhaps allowing Screens to exist while a notification is being handled could be sufficient?

[pwnall]

I think that as we've built out the Web Platform we've come to consider that "live" are an anti-pattern. Modern APIs should return (frozen) snapshots of information, whenever this doesn't harm performance too much. I think this API should use snapshots. In other words, getScreens / getDisplays should return objects whose properties never change.

[michaelwasserman]

Thanks for that insight! In that case, I wonder if it makes sense to modernize the Screen object as obtained through window.screen, to behave in the same manner, or if that object should behave differently from our proposed Screen object as obtained through getScreens(). My naive inclination would be to modernize the existing window.screen object too. Thoughts?

[inexorabletash]

So, for example, the Screen object returned by window.screen might not always be the same object, but once captured e.g. s = window.screen the properties on s would never change? Seems plausible...

It seems like this would be backwards compatible with code written to reference window.screen (or just screen since window is the global...) directly, any code that held a reference (e.g. var s = window.screen) would see the snapshot and not any updates. I could imagine code optimizers doing this (i.e. to save bytes); we could maybe do an HTTPArchive search, but it may just be a matter of taking the chance.

[michaelwasserman]

The updated and consolidated proposal suggests static snapshots of screen information. w3c/window-management#18 discusses this topic further and suggests "file a CSSOM View issues to ask them to deprecate the main screen object, and then cut its properties down to just what is necessary for web compat", so I'll close this issue and proceed as advised there.