Open
Bug 1384127
Opened 7 years ago
Updated 2 years ago
Intermittent browser/base/content/test/general/browser_printpreview.js | print preview mode should be finished by access key -
Categories
(Firefox :: General, defect, P5)
Firefox
General
Tracking
()
NEW
People
(Reporter: intermittent-bug-filer, Unassigned)
References
Details
(Keywords: intermittent-failure, leave-open, Whiteboard: [test disabled])
Filed by: cbook [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=117398427&repo=mozilla-central https://queue.taskcluster.net/v1/task/Tv9CQ7b7RIS---WSXSDuOg/runs/0/artifacts/public/logs/live_backing.log
Comment hidden (Intermittent Failures Robot) |
Updated•7 years ago
|
status-firefox56:
--- → affected
status-firefox57:
--- → affected
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment 4•7 years ago
|
||
On Beta, this is failing with much higher frequency than on trunk, mostly on Windows opt e10s. Gijs, do you know who might have cycles to look at this?
Flags: needinfo?(gijskruitbosch+bugs)
Comment 5•7 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM] from comment #4) > On Beta, this is failing with much higher frequency than on trunk, mostly on > Windows opt e10s. Gijs, do you know who might have cycles to look at this? Not really. I'm not sure what the cause is off-hand. Random screenshots I look at show: - about:home rather than print preview - a blank tab with a spinner - a spinner with the dialog for print preview prep mixed in but the code for opening print preview in that test sure looks... interesting... function openPrintPreview(aCallback) { document.getElementById("cmd_printPreview").doCommand(); executeSoon(function() { if (gInPrintPreviewMode) { executeSoon(aCallback); return; } executeSoon(arguments.callee); }); } Where the callback tries to close print preview somehow. I'm not sure that we can rely on print preview having finished initializing completely after just activating a command, and the recursive clicking of the command makes me wonder if that can exit print preview early, and thus leading to a confused state. So off-hand, my hypotheses would be: 1) something about the content process is slow and we haven't entered print preview completely by the time we exit (even though gInPrintPreviewMode is true), thus meaning we don't exit successfully when e.g. pressing access keys or [esc], thus breaking the test 2) we try to enter/exit multiple times because when the inner callback gets executed gInPrintPreviewMode is still false, and this breaks stuff. It looks like Masayuki-san added this test originally. Maybe they have time to take a look. I don't know why it'd fail more often on beta and/or less often on nightly, either.
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(masayuki)
Comment 6•7 years ago
|
||
Hmm, I made access key handling at replay event phase starting from 56 (bug 1333459). It might affect this bug (Although, looks like no remote children has focus). # Unfortunately, I don't have much time. I guess it's no problem to disable only access key test until somebody can work on this.
Flags: needinfo?(masayuki)
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•7 years ago
|
Flags: needinfo?(ryanvm)
Comment 10•7 years ago
|
||
Skipped on Windows. There'll still be some failures lingering on Linux debug/ASAN, but this'll cut down on the noise a lot at least. https://hg.mozilla.org/integration/mozilla-inbound/rev/23b8b4b23566594fcde199bbd64e8f8a07b9e220
Comment 11•7 years ago
|
||
Pushed by ryanvm@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/23b8b4b23566 Skip browser_printpreview.js on Windows for frequent failures.
Whiteboard: [test disabled]
Comment 12•7 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/a000b6bed029
Whiteboard: [test disabled]
Comment 13•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/23b8b4b23566
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Comment hidden (Intermittent Failures Robot) |
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•