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)

defect

Tracking

()

Tracking Status
firefox56 --- disabled
firefox57 --- disabled

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

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

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)
(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)
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)
Flags: needinfo?(ryanvm)
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
Flags: needinfo?(ryanvm)
Keywords: leave-open
Whiteboard: [test disabled]
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]

We can try re-enabling this after bug 1745247 lands.

Depends on: 1745247
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.