W3C home > Mailing lists > Public > public-browser-tools-testing@w3.org > April to June 2016

RE: Set Window Size

From: Clay Martin <clmartin@microsoft.com>
Date: Wed, 18 May 2016 17:30:47 +0000
To: Andreas Tolfsen <ato@mozilla.com>, "public-browser-tools-testing@w3.org" <public-browser-tools-testing@w3.org>
Message-ID: <CY1PR0301MB15479A46CE11504382FEE03DC3490@CY1PR0301MB1547.namprd03.prod.outlook.com>
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?).

From: Andreas Tolfsen<mailto:ato@mozilla.com>
Sent: Wednesday, May 18, 2016 10:26 AM
To: public-browser-tools-testing@w3.org<mailto:public-browser-tools-testing@w3.org>
Subject: Re: Set Window Size

Sam Uong <samuong@google.com> writes:

> 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:
> >
> > > 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.
> 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.
Received on Wednesday, 18 May 2016 17:31:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:09:53 UTC