Henrik Skupin [:whimboo][⌚️UTC+1] Assignee
	Description • 6 years ago

In cases like bug 1489628 the command hangs and doesn't return. As result Firefox gets killed after the 360s without a reply from Marionette.

> 11:26:42     INFO -  1536344802211	Marionette	TRACE	97 -> [0,5,"WebDriver:GetWindowRect",{}]
> 11:26:42     INFO -  1536344802213	Marionette	TRACE	97 <- [1,5,null,{"x":4,"y":4,"width":1366,"height":768,"state":"maximized"}]
> 11:26:42     INFO -  1536344802216	Marionette	TRACE	97 -> [0,6,"WebDriver:ExecuteScript",{"scriptTimeout":null,"newSandbox":true,"args":[],"filename":"tests/testing/marionette/harness ... width: window.screen.availWidth,\n              height: window.screen.availHeight,\n            }","sandbox":null,"line":22}]
> 11:26:42     INFO -  1536344802233	Marionette	TRACE	97 <- [1,6,null,{"value":{"width":1366,"height":768}}]
> 11:26:42     INFO -  1536344802237	Marionette	TRACE	97 -> [0,7,"WebDriver:SetWindowRect",{"y":null,"x":null,"width":1356,"height":758}]

Note this only happens for tests running on MacOS so far.

	Henrik Skupin [:whimboo][⌚️UTC+1] Assignee
	Comment 1 • 6 years ago

Should be fixed by Andreas' patch on bug 1492499.

	Henrik Skupin [:whimboo][⌚️UTC+1] Assignee
	Comment 2 • 6 years ago

This is not completely fixed yet. I will mark a test failure as blocking in a moment.

	Henrik Skupin [:whimboo][⌚️UTC+1] Assignee
	Comment 3 • 6 years ago

The problem as reported on this bug has been increased since the window manipulation changes have been landed. More and more high frequent intermittent failures appear as tracked by bugs on the dependency list.

Andreas, will you have the time to look at the underlying problem? If not please tell us, so someone else can dive into it. Thanks.

	Andreas Tolfsen ❲:ato❳
	Comment 4 • 6 years ago

I wont have time to look at this within a reasonable timeframe.  I
will add some notes and observations about investigating this that
can be useful.

Most of the new intermittents we have seen following
https://bugzilla.mozilla.org/show_bug.cgi?id=1492499 are related
to Mn tests and test_window_rect.py specifically.  Why are we not
seeing the same amount of failures with WPT WebDriver tests?

One theory I have is that test_window_rect.py is occassionally,
though for what reason I dont know, started in the wrong state.  In
WPT we have much stronger guarantees that the browser is in a
reasonable and safe state before running tests.  The first step
would be to make sure test_window_rect.py is in the right test
before running the tests.

My window manipulation changes did not change any code related to
repositioning the window (window.moveTo), but it did attempt to
make WebDriver:SetWindowRect indempotent.  It is worth reviewing
if this check is correct.

Many of the failures are related to calling WebDriver:SetWindowRect
after the window recovers from a different window state e.g. from
being minimised, maximised, or fullscreen.  That means exitFullscreen
and/or restoreWindow could be wrong.  I somewhat suspect we are not
always receiving the expected events (for various reasons) and
instead relying on the TimedPromises to time out.

The arbitrary 1.5 second timeout of TimedPromise would explain why
we are only seeing these problems intermittently.

I hope this helps!

	Henrik Skupin [:whimboo][⌚️UTC+1] Assignee
	Comment 5 • 6 years ago

Setting needinfo for myself because I will have to take a look at this. First thing I might want to do is to add some more debug/trace logging so we get some more information about performance and reliability of the individual window manipulation commands.