Closed Bug 690989 Opened 13 years ago Closed 11 years ago

Intermittent test_fullscreen-api.html | [rollback] FSE should be e('fse') - got null, expected [object HTMLDivElement], | [rollback] FSE should be e('fse-inner') - got null, expected [object HTMLDivElement], | Test timed out.

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla19
Tracking Flags:
Tracking Status
firefox14 --- wontfix
firefox15 --- affected
firefox16 --- affected
firefox17 --- wontfix
firefox18 --- fixed
firefox19 --- fixed
firefox-esr17 --- fixed

People

(Reporter: philor, Assigned: cpearce)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

Patch: ensure we're focused before requesting fullscreen
(deleted), patch
smaug
: review+
Details | Diff | Splinter Review
Patch: Work around fullscreenchange events sometimes being dispatched before fullscreen transition completes on Linux.
(deleted), patch
smaug
: review+
Details | Diff | Splinter Review
https://tbpl.mozilla.org/php/getParsedLog.php?id=6633501&tree=Mozilla-Inbound Rev3 WINNT 5.1 mozilla-inbound debug test mochitests-1/5 on 2011-09-30 18:22:34 PDT for push a89bf0c36977 ###!!! ASSERTION: Failed to make GL context current!: 'succeeded', file e:/builds/moz2_slave/m-in-w32-dbg/build/gfx/thebes/GLContextProviderWGL.cpp, line 294 TEST-UNEXPECTED-FAIL | /tests/content/html/content/test/test_fullscreen-api.html | application timed out after 330 seconds with no output
Benoit, Jeff, I believe you guys were looking into something like this?
WGL eh? Why would WGL, or any GL, be used at all here? With jgilbert we were looking into the WebGL mochitest, which consists of many pages using WebGL, eventually starting to fail using EGL and falling back to WGL instead. This is a priori even 'worse': why would that be using any GL at all on Windows? On Windows, we're supposed to only use GL for WebGL at all.
Might as well make the takeover complete.
Summary: Intermittent test_fullscreen-api.html | application timed out after 330 seconds with no output → Intermittent test_fullscreen-api.html | [rollback] FSE should be e('fse') - got null, expected [object HTMLDivElement], | [rollback] FSE should be e('fse-inner') - got null, expected [object HTMLDivElement], | Test timed out.
Or maybe I'll wait for a few more random failures, and change it to "Linux test_fullscreen-api.html | somebody broke it"
This no longer looks like a WebGL related thing, and is now on all platforms. Also, either something regressed around 02/06/12, or that's when TinderboxPushlog Robot started working, because reports really pick up after then.
OS: Windows XP → All
Hardware: x86 → All
I think the problem could be that some of the tests' requests for fullscreen could be failing because their document isn't the currently focused document, so this patch explicitly requests focus as part of requesting fullscreen.
Assignee: nobody → cpearce
Status: NEW → ASSIGNED
Attachment #617382 - Flags: review?(bugs)
Comment on attachment 617382 [details] [diff] [review] Patch: ensure we're focused before requesting fullscreen We can try this.
Attachment #617382 - Flags: review?(bugs) → review+
Target Milestone: --- → mozilla14
https://hg.mozilla.org/mozilla-central/rev/137acae37ff9
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → NEW
cpearce, do you have any more ideas for this? It is still a pretty regular failure on OrangeFactor.
(In reply to Ed Morley [:edmorley] from comment #687) > cpearce, do you have any more ideas for this? It is still a pretty regular > failure on OrangeFactor. I suspect it this orange the same root cause as the recent spike in pointerlock and orange; the fullscreenchange event is firing before the transition is to/from fullscreen is complete. I suspect we could add a similar work around like I did for bug 745047, I just haven't had spare time to get around to trying it.
(In reply to Chris Pearce (:cpearce) from comment #693) > (In reply to Ed Morley [:edmorley] from comment #687) > > cpearce, do you have any more ideas for this? It is still a pretty regular > > failure on OrangeFactor. > > I suspect it this orange the same root cause as the recent spike in > pointerlock and orange; the fullscreenchange event is firing before the > transition is to/from fullscreen is complete. > > I suspect we could add a similar work around like I did for bug 745047, I > just haven't had spare time to get around to trying it. Do you have a rough ETA for when you might be able to look at this? :-)
(In reply to Ed Morley [:edmorley] from comment #903) > (In reply to Chris Pearce (:cpearce) from comment #693) > > I suspect we could add a similar work around like I did for bug 745047, I > > just haven't had spare time to get around to trying it. > > Do you have a rough ETA for when you might be able to look at this? :-) I'm working on it while waiting for builds...
(In reply to Chris Pearce (:cpearce) from comment #907) > > Do you have a rough ETA for when you might be able to look at this? :-) > > I'm working on it while waiting for builds... 12 more failures until we hit 1000 (at which point I'll be disabling this). Did you have any luck in-between builds? :-)
(In reply to Ed Morley [:edmorley] from comment #989) > (In reply to Chris Pearce (:cpearce) from comment #907) > > > Do you have a rough ETA for when you might be able to look at this? :-) > > > > I'm working on it while waiting for builds... > > 12 more failures until we hit 1000 (at which point I'll be disabling this). Please don't disable the fullscreen tests. I'll get to this. If the failure mode *changes* we can still detect regressions, so the tests are still useful with random failures. > Did you have any luck in-between builds? :-) No. After thinking about it more I figured that this failure shouldn't be able to be worked around the same was as bug 745047.
If you don't get to it before next Monday, we will continue seeing it fail until December 2013 - it's esr17 time.
Why can't we just disable this on the ESR branch? I'm fine with that.
Progress report: I have a work-around that looks promising, got a test run here looking pretty green on Linux opt: https://tbpl.mozilla.org/?tree=Try&rev=b2ccb23e6d39 However it's perma orange on OSX, but assuming none of the pending Linux boxes go orange at least we know that the work-around *in theory* should help on OSX too, it's just a matter of debugging further on that platform...
I think the problem is that the process of going fullscreen is spread across several asynchronous steps, and when the tests run fast (like it does in opt builds) we can end up firing the "fullscreenchange" event before the transition finishes, and the remaining steps of the incomplete transition interfere with any fullscreen state changes made in the listener. I had tried to make Gecko not dispatch "fullscreenchange" until the transition is complete a few months back, but I got stuck debugging remotely on Try. So until I can get back to that, we can apply a work around similar to what we applied to the pointer lock tests; we can always wait until the fullscreen transition is complete before firing the "fullscreenchange" event listener's callback. The fullscreen tests are only (regularly?) failing on Linux, so I only do the work around on Linux. Green: https://tbpl.mozilla.org/?tree=Try&rev=e42cd97db1fc See my previous try push in my earlier comment for gratuitous testing on Linux. This work around doesn't work on MacOSX7+ because the transition is takes several seconds, and I'd need to inject a timeout to make the work around work there, but since the tests aren't failing on MacOSX7+, I think we should just leave it be for now.
Attachment #669371 - Flags: review?(bugs)
Comment on attachment 669371 [details] [diff] [review] Patch: Work around fullscreenchange events sometimes being dispatched before fullscreen transition completes on Linux. Sorry, took some time. Lots of small changes.
Attachment #669371 - Flags: review?(bugs) → review+
m1 green on all platforms, except WinXP which hasn't started yet... https://tbpl.mozilla.org/?tree=Try&rev=67049d31cac3
https://hg.mozilla.org/mozilla-central/rev/e71ee7ecd856
Status: NEW → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: mozilla14 → mozilla19
Chris, I was hoping to land this on Aurora, but it doesn't apply cleanly. Can you please post a rebased patch?
Whiteboard: [orange]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yeah, let's not recycle this ancient bug for what is most assuredly a new regression. Filed bug 909008 to track the new failures.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: