Re: Set Window Size

Doing a quick search I found this:
https://developer.mozilla.org/en-US/docs/Web/Events/resize
Which led me to this:
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-resize

Which seems like what we want per it's definition:
"A user agent MUST dispatch this event when a document view has been resized. This event type is dispatched after all effects for that occurrence of resizing of that particular event target have been executed by the user agent."

Since Set Window Size resizes once (and isn't a continuous resize like if a user clicks/drags to resize the browser) it should only fire once, although I don't know if this accounts for the content completing reflow. Although it does say:
"User agents which support continuous reflow of the document's layout during user-initiated resizing MUST dispatch this event synchronously after each reflow of the document."

Where it calls out reflow of the document specifically. Thoughts?
________________________________
From: Sam Uong <samuong@google.com>
Sent: Wednesday, May 18, 2016 4:11:24 PM
To: Andreas Tolfsen; public-browser-tools-testing@w3.org
Subject: Re: Set Window Size

Setting the window size to > the maximum window size is not super common, and maximize probably handles the use case most users are looking for. But I've seen some teams try to set up a very tall window so that they could fit all the content into the viewport, as well as teams with kiosk apps that run in very small monitors.

On Wed, May 18, 2016 at 3:45 PM Andreas Tolfsen <ato@mozilla.com<mailto:ato@mozilla.com>> wrote:
Clay Martin <clmartin@microsoft.com<mailto:clmartin@microsoft.com>> writes:

> Andreas Tolfsen <ato@mozilla.com<mailto:ato@mozilla.com>> writes:
>
>> Sam Uong <samuong@google.com<mailto:samuong@google.com>> writes:
>
>> > We've also noticed that even when it does change size, it sometimes
>> > changes to a size that is different from the one requested. This
>> > happens when window managers clip windows to fit into the screen,
>> > or when they decide that it is big enough that the user meant to
>> > maximize.
>>
>> This is to be expected, and incidentally why the specification makes
>> no guarantees that the window is the requested size when returning.
>>
>> Marionette contains such a check at the moment, but this is
>> non-confirming behaviour and will be removed shortly.
>
> No matter what it's tricky as there are a lot of edge cases
> that won't work 100% of the time as listed. That said some
> level of effort seems reasonable (even delaying a set time before
> returning). Sadly I don't have data for average resize time between
> frame and content. Are cases like setting the window size to > window
> manage common/promoted? I guess there could be value in it? Trying to
> think of a proper use case (maybe testing a website for a large screen
> display on a small screen/resolution?).

Mandating an arbitrary wait duration seems like a pretty random solution
to the problem when some (if not most) windows can be resized pretty
much instantly.

Anticipating the window size to grow > or < the current window size
could not be guaranteed either because the window manager might have
custom rules preventing it. (jgraham used tiling window managers as an
example of this.)