Closed Bug 1244991 Opened 8 years ago Closed 8 years ago

Intermittent e10s failure browser_backgroundTab.js | panel shouldn't have shown from a background tab

Categories

(Firefox :: Tours, defect)

defect
Not set
normal
Points:
3

Tracking

()

RESOLVED FIXED
Firefox 48
Iteration:
48.2 - Apr 4
Tracking Status
e10s + ---
firefox45 --- wontfix
firefox46 --- disabled
firefox47 --- disabled
firefox48 --- fixed
firefox-esr45 --- unaffected

People

(Reporter: MattN, Assigned: mikedeboer)

References

(Blocks 2 open bugs)

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled])

Attachments

(1 file)

e10s on 10.6 and linux32
In test test_info_target_callback

INFO -  154 INFO Entering test test_info_target_callback
INFO -  155 INFO TEST-UNEXPECTED-FAIL | browser/components/uitour/test/browser_UITour3.js | Event did not happen within 5 seconds. -
INFO -  Stack trace:
INFO -  chrome://mochitests/content/browser/browser/components/uitour/test/head.js:add_UITour_task/genFun/</</</funcPromise<:388
INFO -  resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:Handler.prototype.process:940
INFO -  resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:this.PromiseWalker.walkerLoop:816
INFO -  156 INFO == Done test, doing shared checks before teardown ==
Whiteboard: [test disabled]
Blocks: e10s-tests
tracking-e10s: --- → +
I think bug 1248849 should fix the bug in showInfoPromise that caused this.

Try push with chaos mode enabled to test this theory: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a77b3c742b99
Depends on: 1248849
(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)
 
Note that this may already be fixed by bug 1248849 so we could have tried uplifting that instead…
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Iteration: --- → 48.2 - Apr 4
Points: --- → 3
Flags: qe-verify-
Flags: firefox-backlog+
Since we don't have absolute control over the sequence order of all the various messages that are sent between the content and the main process, we need to add a gate to make sure we wait long enough before we continue to test showPopup.

The green try run can be found in comment 12.
Attachment #8736353 - Flags: review?(MattN+bmo)
IMO, the mix-'n-match of synchronous and asynchronous APIs in UITour is something that needs to be addressed at some point in the client library. But that might be hard if we have to be backwards compatible with that AP surface.
*API
Keywords: leave-open
Comment on attachment 8736353 [details] [diff] [review]
Patch v1: re-enable browser_backgroundTab.js UITour test

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

Thanks.

Could you make the commit message more specific now (mentioning visibility / async tab switching, etc.)?
Attachment #8736353 - Flags: review?(MattN+bmo) → review+
https://hg.mozilla.org/integration/fx-team/rev/43ee605bf4666503c19e2b5a27972e8cd4a307aa
Bug 1244991: re-enable browser_backgroundTab.js UITour test and to make sure it doesn't fail on slower hardware, wait for the visibilitychange event explicitly since it may occur later than the tab open and switch. r=MattN
https://hg.mozilla.org/mozilla-central/rev/43ee605bf466
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
You need to log in before you can comment on or make changes to this bug.