Intermittent test_window_maximize.py TestWindowMaximize.test_maximize | IOError: Process killed because the connection to Marionette server is lost. Check gecko.log for errors (Reason: Connection timed out after 360.0s)

RESOLVED WORKSFORME

Status

defect
RESOLVED WORKSFORME
2 years ago
2 years ago

People

(Reporter: intermittent-bug-filer, Assigned: bdahl)

Tracking

Version 3
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [stockwell disabled])

Attachments

(3 attachments, 1 obsolete attachment)

Comment on attachment 8870571 [details]
Bug 1367227: Disable Marionette window maximize tests in headless mode;

https://reviewboard.mozilla.org/r/142030/#review145684
Attachment #8870571 - Flags: review?(bdahl) → review+
Pushed by dburns@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/2b4c8ed50e42
Disable Marionette window maximize tests in headless mode; r=bdahl
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/72ed8fb02c63
Disable Marionette window rect tests in headless mode. r=bdahl
The oranges are gone now, but let's leave this bug open for the eventual fixing & re-enabling.
Assignee: nobody → bdahl
Keywords: leave-open
Whiteboard: [stockwell disabled]
During MakeFullScreen, headless wasn't triggering a size mode and full screen changed event which caused marionette to hang waiting for a resize event. I tried to match more of the behavior of the linux and windows backend with the new code.
Attachment #8872000 - Flags: review?(jmuizelaar)
As mentioned on IRC, the current code doesn't actually emulate what  "View > Enter Full Screen" does and it will cause the browser to immediately try to exit fullscreen mode because it triggers the event on a chrome window and it's expected to be on a content window (follow aBrowser in [1]). This doesn't seem to be an issue on various platforms because the exit is ignored while the full screen transition is in progress. The new way does was browser.js does [2].

[1] http://searchfox.org/mozilla-central/rev/a14524a72de6f4ff738a5e784970f0730cea03d8/browser/base/content/browser-fullScreenAndPointerLock.js#429
[2] http://searchfox.org/mozilla-central/rev/a14524a72de6f4ff738a5e784970f0730cea03d8/browser/base/content/browser.js#3229
Attachment #8872004 - Flags: review?(ato)
And a try run (still waiting on MacOS, but looks good elsewhere): https://treeherder.mozilla.org/#/jobs?repo=try&revision=2f02bdaab6bc45545ea9dbe6ed1fdd8282f39bc5
Blocks: 1356681
Attachment #8872000 - Flags: review?(jmuizelaar) → review+
Attachment #8872004 - Flags: review?(ato) → review+
Looks like I should have waited on those osx jobs... It appears that some of the resize events on mac come before the fullscreen transition is complete. I've switched it to now use sizemodechange, as that seems like the more reliable way.
Attachment #8872840 - Flags: review?(ato)
Attachment #8872004 - Attachment is obsolete: true
Comment on attachment 8872840 [details] [diff] [review]
Part 2 - Trigger fullscreen the same way Firefox does.

Review of attachment 8872840 [details] [diff] [review]:
-----------------------------------------------------------------

r+, push when confident.
Attachment #8872840 - Flags: review?(ato) → review+
Pushed by bdahl@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/8a78af3f0280
Part 1 - Match headless fullscreen behavior to other widget backends. r=jrmuizel
https://hg.mozilla.org/integration/mozilla-inbound/rev/812a3f2737d4
Part 2 - Trigger fullscreen the same way Firefox does. r=ato
Oranges are gone.
Keywords: leave-open
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
No known fix -> WFM.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.