Closed Bug 1656892 Opened 2 years ago Closed 2 years ago

Page navigation can no longer be performed from a tab that has encountered Bug 1656887


(Core :: DOM: Navigation, defect, P2)

Windows 10



Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- wontfix
firefox79 --- wontfix
firefox80 --- wontfix
firefox81 --- wontfix
firefox82 --- wontfix
firefox83 --- fixed


(Reporter: emilghitta, Unassigned)




(Keywords: regression)


(1 file)

Attached image errorprint.gif

Affected versions

  • 81.0a1 (BuildId:20200727203201)
  • 80.0b3 (BuildId:20200803045446)
  • 79.0 (BuildId:20200720193547)
  • 78.1.0esr (BuildId:20200722151235)

Unaffected versions

  • 68.11.0esr (BuildId:20200720181548)

Affected platforms

  • Windows 10 64bit

Unaffected platforms

  • Ubuntu 18.04 64bit
  • macOS 10.14

Steps to reproduce

  1. Launch Firefox.
  2. Access the about:support page.
  3. Hit CTRL + P
  4. Select the print to PDF option.
  5. Click the Print button.
  6. Click the X button from the preparing dialog before the “Save print output as” prompt is displayed (or press the escape button before the “Save print output as” prompt is displayed).
  7. Repeat step 3.
  8. Enter a valid url inside the address bar and press enter.

Expected result
It seems that there are 2 different faulty behaviors encountered here:

  • Step 7 -> The print setup is properly displayed and the print job can be successfully initiated. (logged Bug 1656887 for this behavior).
  • Step 8 -> Nothing happens, the navigation is not performed and the about:support page remains open on that tab (Even if you try clicking on the homepage button).

Actual result

  • Step 7 -> Print preview error. Some printing functionality is not currently available. ( logged Bug 1656887 for this behavior).
  • Step 8 -> Page navigation can be successfully performed.

Regression Range


  • [Suggested Severity] Having in mind the outcome if this is reproduced...I think that this fits inside the S2 category.
  • This is not reproducible on remote pages.
  • I think that, maybe, fixing the behavior from 1656887 will implicitly fix this one as well. Since there are 2 different behaviors I've decided to file 2 separate bugs.
Has Regression Range: --- → yes
Has STR: --- → yes

emil.ghitta triaging as reo for 79, could you set a priority and severity for this bug?

Flags: needinfo?(emil.ghitta)

Redirecting the ni? to Neha (triage owner). Also QA was informed to suggest the severity (instead of setting it directly) until further notice.

Flags: needinfo?(emil.ghitta) → needinfo?(nkochar)
Severity: -- → S2
Flags: needinfo?(nkochar) → needinfo?(agakhokidze)
Priority: -- → P2

This looks suspiciously like we're failing to call nsDocumentViewer::SetIsPrinting(false) on error to unblock navigation. Unfortunately my workstation died recently and I don't currently have a Windows environment set up to build/debug on.

:Neha Triaging as REO for 79, can you assign this to someone?

A lot is changing in printing because of Shirley release. I'm unable to reproduce on Mac as with the new print UI, the print to PDF option is not available at least on Mac. Emil, can you re-test and confirm if this is still a problem?

Flags: needinfo?(nkochar)
Flags: needinfo?(emil.ghitta)
Flags: needinfo?(agakhokidze)

This was reproducible for the old-ui at some point. But Bug 1656887 is no longer reproducible (may have been fixed by the patch for Bug 1636728 per the mozregression find-fix pushlog).

Closed: 2 years ago
Flags: needinfo?(emil.ghitta)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.