- 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.>
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