The print preview opens for a different tab instead of the desired local about page
Categories
(Toolkit :: Printing, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr78 | --- | unaffected |
| firefox84 | --- | unaffected |
| firefox85 | --- | unaffected |
| firefox86 | --- | verified |
People
(Reporter: emilghitta, Assigned: emmamalysz)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression, Whiteboard: [print2020_v86] [old-ui-] )
Attachments
(2 files)
localPages.gif
Affected versions
- Firefox 86.0a1 (BuildId:20201218095607)
Affected platforms
- Windows 10 64bit
- macOS 10.14
- Ubuntu 20.04 64bit.
Steps to reproduce
- Launch Firefox.
- Open a random webpage (non about/local page).
- Open a different tab and access the about:support page.
- Hit CTRL + P on the about page.
Expected result
- The print preview is displayed for the about page.
Actual result
- The print preview is displayed on a different tab.
Regression Range
- This seems to be a regression:
- Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=6307b67c66ffa34fdbdb8481cc95f58a5cc8df29&tochange=84d74806a0f714937f8de369fef595c5220f9381
- Potential regressor: Bug 1670122
Notes
- For further information please observe the attached screencast.
- It seems that the only way to trigger the print preview for the local pages is by closing all the other tabs.
- This issue is reproducible with both Fission enabled and disabled.
- [Suggested Severity] I think that S3 fits for this issue.
|
Reporter | |
Comment 1•3 years ago
|
||
Hi Emma,
It seems that mozregression pointed out Bug 1670122 for causing this regression.
The pushlog from the bug's description was generated after a second bisection. At first, It gave me this one.
I also can confirm that this issue is not reproducible with the last release without & reproducible with the first release with builds from here.
Can you please take a look?
Thank you!
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 2•3 years ago
|
||
|
|
Assignee | |
Updated•3 years ago
|
|
||
Updated•3 years ago
|
Pushed by emalysz@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/eb3ff7d6b951 use focused browsing context for print preview if it is currently active r=mstriemer
|
||
Comment 4•3 years ago
|
||
| bugherder | ||
|
||
Updated•3 years ago
|
|
|
||
Comment 5•3 years ago
|
||
Moving things to 88, cause we're mostly on Proton these days…
|
|
||
Updated•3 years ago
|
|
|
Reporter | |
Comment 6•3 years ago
|
||
This issue is verified fixed using Firefox 86.0 on Windows 10 64bit, macOS 10.13 and Ubuntu 20.04
|
||
Comment 7•2 years ago
|
||
Mark, I'm trying to understand this code. I guess the wrong browser comes from:
<command id="cmd_print" oncommand="PrintUtils.startPrintWindow(gBrowser.selectedBrowser.browsingContext);"/>
Why is gBrowser.selectedBrowser.browsingContext the wrong thing when an about: page is open and focused? I'd like to add a comment to this code explaining what's going on, because it's not at all obvious.
|
|
||
Comment 8•2 years ago
|
||
I misread this code. 'gBrowser.selectedBrowser.browsingContext' is the right thing in that case and Services.focus.focusedContentBrowsingContext is the wrong thing. That's the wrong thing, presumably because focusedContentBrowsingContext isn't set to a content process browser such as the one for about: pages.
So I guess my real question is why we override the passed BrowsingContext with Services.focus.focusedContentBrowsingContext? We appear to have started using that it https://phabricator.services.mozilla.com/D94467 so it seems the answer is "to get the correct BrowsingContext when printing 'selection only' and printing wasn't initiated from the context menu."
|
|
||
Comment 9•2 years ago
|
||
FWIW I filed bug 1748846 for this.
|
|
||
Updated•2 years ago
|
Description
•