webdriver icon indicating copy to clipboard operation
webdriver copied to clipboard

Should window sizing commands wait before content has finished resizing before returning

Open InstyleVII opened this issue 7 years ago • 5 comments

There is currently a gray area in the specification when doing window sizing for: Set Window Rect Maximize Fullscreen

Set Window Rect explicitly says to set the browser chrome size in CSS pixels but makes no mention of waiting for the web content to resize before returning. Maximize also has this issue where we state that we should resize the chrome Fullscreen as it currently is only resizes the element which is okay for now (as that would assumed resizing the content is waited for since the element becomes all of the displayed content) however if this changes to be the equivalent of a browser fullscreen it will suffer this problem as well.

InstyleVII avatar Mar 21 '18 18:03 InstyleVII

My current thoughts:

Set Window Rect should definitely wait for content to resize. The main usage of this I envision is that developers are setting a specific size to validate content is in the right position. I have had internal testers from partner teams reference us not waiting for content to resize which means their element screenshot command doesn't get the correct screenshot and tests fail.

Maximize is on the fence, I could see it being either area. The issue is the developer has no control over how many pixels Maximize is going to size the window to, so validating content looks a certain way maximized really doesn't make sense. However that wouldn't stop them from doing so and expecting it to work like my proposal for Set Window Rect.

Fullscreen is fine if we leave it the way it is but I imagine at some point we'll also add a browser fullscreen which would have this issue as well.

InstyleVII avatar Mar 21 '18 18:03 InstyleVII

It might also be worth having the resize of the content obey the implicit wait timeout and define it as waiting for the next paint or something like that (there could be long-running script that interferes with the content resizing).

Lastly we could also add implicit wait to things we expect to validate layout like the screenshot command (ensuring that it waits implicitly for content resizing first).

InstyleVII avatar Mar 23 '18 20:03 InstyleVII

@AutomatedTester Pinging on this as no one has commented yet. Thoughts?

InstyleVII avatar Apr 30 '18 17:04 InstyleVII

How would we know that content has resized? How would we test for that change in a meaningful way. A lot of this work is passing a request off to the OS window manager to do some work for us and then returning.

AutomatedTester avatar May 01 '18 13:05 AutomatedTester

I came here to see, if the api guarantees content is resized before returning. The above discussion only made it worse, as there are references to some two sorts of fullscreen which are not the same? Does it affect the api user somehow?

Further, the api doc for selenium says that "Fullscreen the current window if it is not already fullscreen" .... but reading the w3c spec I can not confirm the "if it is not already fullscreen"-part of it: so, I cannot be sure if the web-app/elements are supposed to get repeated fullscreen events or not, when calling the api repeatedly.

So now we have 3 uncertain issues on the fullscreen api.

karniemi avatar Aug 18 '22 15:08 karniemi