Add "emulation.setScreenSettingsOverride" command.

[lutien]

Closes #981.

My approach was to more or less to document the current implementation of Responsive Design mode behaviour of browsers. That's why I think for this specific command it makes more sense to override it on the CSS spec level since it touches exactly the data which we currently override. That's also why I think we have to override not just dimensions, but the coordinates as well (they are currently reset when setting the dimensions). It might be useful in the future to allow in the future to set coordinates as well (?). So that's why I came up with the name setScreenAreaOverride rather than setScreenDimensionsOverride or something else.

The draft PR in the CSS spec to illustrate how it might look like there: w3c/csswg-drafts#13091.

Let me know what you think.

---

Preview | Diff

[sadym-chromium]

With the [feature request] Specification for emulation · Issue #151 · w3c/window-management for Window Management specification, I believe eventually we want to emulate screens fully. Can we make the command more generic so that it can be extended with other emulated properties?

[lutien]

With the [feature request] Specification for emulation · Issue #151 · w3c/window-management for Window Management specification, I believe eventually we want to emulate screens fully. Can we make the command more generic so that it can be extended with other emulated properties?

Sure, we can do that. I was just thinking that since we already have orientation override in a separate command and device pixel ration in the setViewport command. Maybe we want to have the rest separate? But maybe the other way is true, and we rather want to group it and maybe later move other properties in this command?

[jgraham]

I think grouping makes more sense than having many commands that all need to be sent separately. If it makes sense later we can make existing commands options for the new command.

[lutien]

Alright, I've renamed the command to emulation.setScreenSettingsOverride.

[sadym-chromium]

General thoughts: eventually, to emulate window.getScreenDetails().screens, we will need to introduce the concept of emulated screen. I wonder how this approach can be extended later on to fully support emulations of multiple screens, and moving browser windows around them.

[lutien]

General thoughts: eventually, to emulate window.getScreenDetails().screens, we will need to introduce the concept of emulated screen. I wonder how this approach can be extended later on to fully support emulations of multiple screens, and moving browser windows around them.

I think we could introduce then screen IDs and specify this emulation for a screen id. We will have to decide then if the emulation keeps getting attached to a browsing context/user context no matter on which screen it's, or it will be attached to that screen and if browser window are moved around it uses different settings.
So I think we can still make it work, but as you say that's something what we will have to do eventually.

[sadym-chromium]

General thoughts: eventually, to emulate window.getScreenDetails().screens, we will need to introduce the concept of emulated screen. I wonder how this approach can be extended later on to fully support emulations of multiple screens, and moving browser windows around them.

I think we could introduce then screen IDs and specify this emulation for a screen id. We will have to decide then if the emulation keeps getting attached to a browsing context/user context no matter on which screen it's, or it will be attached to that screen and if browser window are moved around it uses different settings. So I think we can still make it work, but as you say that's something what we will have to do eventually.

It's not a blocker.

[sadym-chromium]

LGTM, thanks! I'd only propose to implement the global config right away, but I'l leaving it up to you.