Re: Set Window Size

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.

On Wed, May 18, 2016 at 5:16 AM James Graham <james@hoppipolla.co.uk> wrote:

> On 18/05/16 13:06, Andreas Tolfsen wrote:
> > Clay Martin <clmartin@microsoft.com> writes:
> >
> >> Sam Uong <samuong@google.com> writes:
> >>
> >>> Does this look at the content of the page, or does it wait for
> >>> (something like) window.outerHeight/Width to change?
> >>
> >> We currently just set the frame to resize and the rest propagates but
> >> we plan to change that to verify content also resizes as we've seen
> >> issues related to screenshot because of it (user resizes, takes a
> >> screenshot and the height/width is incorrect because the resize hasn't
> >> finished, adding a sleep fixed it for the user).
> >
> > I feel the specification in its current form implies
> > that the command should be performed synchronously in
> > http://w3c.github.io/webdriver/webdriver-spec.html#set-window-size,
> > although it uses a rather hand-wavy language to achieve it.
> >
> > Previously we had a paragraph near the top of the document stating that
> > WebDriver provided a (mostly) blocking and synchronous API. Do you feel
> > it is worth pointing this out as something applying to the spec as a
> > whole?
> >
> > Related to Set Window Size directly, do we feel it is necessary to add a
> > provision to wait for the window to change its size before returning?
> >
>
> The window may never change its size e.g. if you have a tiling wm it may
> ignore windows' requests to change their own size. Or the size may
> change multiple times e.g. if there is a transition animation that
> exposes intermediate states to the window.
>
> In general I doubt we can make strong guarantees about the behaviour
> across different OSes here. For Servo we have considered implementing
> some logic to wait for a quiescent state in the window size e.g. no size
> changes recorded within 200ms, and then returning whatever the window
> size is at that point. In the case of the WM blocking the size change
> one would therefore incur a mandatory delay before this command returns.
> But I think it should be a rare enough command that making it
> super-performant isn't that important.
>
>