Page navigation can no longer be performed from a tab that has encountered Bug 1656887
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
People
(Reporter: emilghitta, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
1.51 MB,
image/gif
|
Details |
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
- Launch Firefox.
- Access the about:support page.
- Hit CTRL + P
- Select the print to PDF option.
- Click the Print button.
- 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).
- Repeat step 3.
- 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
- The issue encountered in step 7 seems be reproducible on older builds as well (54.0a1) but the issue mentioned for step 8 seems to be caused by a recent change:
- Pushlog for step 8: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=272e3c98d0029fe73c0a57c45bc3b11ffa0e2bee&tochange=450aaa84a055ede7b47fed95b59f1a948749ba6e
- Pottential regressor for step 8: Bug 1637869
Notes
- [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.
Reporter | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
emil.ghitta triaging as reo for 79, could you set a priority and severity for this bug?
Reporter | ||
Comment 2•4 years ago
|
||
Redirecting the ni? to Neha (triage owner). Also QA was informed to suggest the severity (instead of setting it directly) until further notice.
Updated•4 years ago
|
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
:Neha Triaging as REO for 79, can you assign this to someone?
Comment 5•4 years ago
|
||
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?
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 6•4 years ago
|
||
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).
Updated•4 years ago
|
Description
•