Add commands for resizing and positioning browser windows

[CanadaHonk]

See WebDriver classic spec: https://www.w3.org/TR/webdriver/#resizing-and-positioning-windows
See also CDP equivalents: https://chromedevtools.github.io/devtools-protocol/tot/Browser/#method-getWindowBounds & https://chromedevtools.github.io/devtools-protocol/tot/Browser/#method-setWindowBounds

[jgraham]

So I propose we do this as follows:

A command browser.getWindows() that provides a list of WindowInfo objects which might look something like:

browser.Window = text # Window Id

browser.WindowInfo = {
  window: browser.Window,
  contexts: [*browsingContext.Context], # Top level browsing contexts
  bounds: browser.WindowBounds
}

browser.WindowBounds = {
  top: js-uint,
  left: js-uint,
  width: js-uint,
  height: js-uint,
  state: "normal" / "maximized" / "minimized" / "fullscreen",
}

The command should allow providing a list of contexts or window ids to limit the results to just those windows or the windows containing those contexts.

If that already provides the bounds we don't need a separate getter command. But we'd want a browser.setWindowBounds command with parameters like:

browser.SetWindowBoundsParameters = {
  window: browser.Window,
  bounds: browser.WindowsBoundsParameters
}

browser.WindowsBoundsParameters = browser.WindowState // browser.WindowRect

browser.WindowState = {
  type: "maximized" / "minimized" / "fullscreen"
}

browser.WindowRect = {
  type: "rect",
  top: js-uint,
  left: js-unit,
  width: js-uint,
  height: js-unint
}

[css-meeting-bot]

The Browser Testing and Tools Working Group just discussed Resize and positioning windows.

The full IRC log of that discussion

<AutomatedTester> Topic: Resize and positioning windows
<AutomatedTester> Github: https://github.com//issues/398
<AutomatedTester> whimboo: I've added this and was curious if this is a high level priority from client vendors
<AutomatedTester> jgraham: Classic webdriver has support for resizing and positioning. From the point of view of supporting classic we should add this
<AutomatedTester> ... it has a lot of capabilities that are not available through device emulation
<AutomatedTester> ... in classic webdriver there is some confusion between top level browser context and the OS window
<AutomatedTester> ... the suggestion in the issue is that we have something has an a OS window id
<AutomatedTester> ... and have top level context in that OS window
<AutomatedTester> ... and then dimensions that are available
<AutomatedTester> ... and then you can set the state of the window (max/min)
<shs96c> q+
<AutomatedTester> ... are there other use cases that we should see about addressing?
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> shs96c: This is basically what we need to implement (points to classic spec section 11)
<AutomatedTester> ... we are just going to lft that and shift it?
<AutomatedTester> jgraham: yes
<orkon> q+
<whimboo> q+
<AutomatedTester> ... webdriver classic does a lot of things that says "please try" and it can fail
<AutomatedTester> shs96c: yes... like mobile can';t do a lot of those things
<AutomatedTester> jgraham: it is also fallible in some cases in there is a window manager that has no idea how to do that. E.g. window managers don't have max
<AutomatedTester> shs96c: from where I am sitting this proposal looks good
<AutomatedTester> ack next
<AutomatedTester> orkon: from our perspective the proposal looks good
<AutomatedTester> ... for the other things these are outside the browser
<AutomatedTester> ... and more window manager controls
<AutomatedTester> ... it would be good to get messages coming back about what can/cant be done
<shs96c> q+
<AutomatedTester> shs96c: people historically run tests in as big as possible and know it's not always perfect
<AutomatedTester> ack next
<whimboo> https://github.com/web-platform-tests/wpt/pull/41588/files
<AutomatedTester> whimboo: one follow up is I have updated the tests recently
<AutomatedTester> ... so what ever we do in bidi should be easy to copy these tests across
<shs96c> whimboo: can you please share a link to that spreadsheet?
<AutomatedTester> ... the priority on this still correct as it has a high priority
<orkon> https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0
<whimboo> https://docs.google.com/spreadsheets/d/1Cg3rifrBZClIitU3aFW_WDv64gY3ge8xPtN-HE1qzrY/edit#gid=0
<AutomatedTester> q?
<AutomatedTester> ack next
<AutomatedTester> shs96c: for selenoium it is still a high priority for what I mentioned earlier
<AutomatedTester> ... one quick question, do we want to send events back or is it fire and forget?
<AutomatedTester> jgraham: I think we should have a response with details of the window size it got to
<AutomatedTester> ... and we can have an event that is fired if a new window is created or a resize happens from something else
<AutomatedTester> shs96c: that would end up with 2 events? a window resize, window create
<AutomatedTester> jgraham: 3. one for resize, create and destroyed
<orkon> q+
<AutomatedTester> ack next
<AutomatedTester> orkon: for events we should discuss events separately as that is not part of the current proposal
<AutomatedTester> jgraham: I agree. It is lower priority and a lot of it is covered by context created

[jgraham]

#752

[whimboo]

@jgraham I assume the issue can be closed now?