Closed Bug 1683318 Opened 4 years ago Closed 4 years ago

The print preview opens for a different tab instead of the desired local about page

Categories

(Toolkit :: Printing, defect, P1)

Firefox 86
defect

Tracking

()

VERIFIED FIXED
86 Branch
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)

Attached image localPages.gif (deleted) —

Affected versions

  • Firefox 86.0a1 (BuildId:20201218095607)

Affected platforms

  • Windows 10 64bit
  • macOS 10.14
  • Ubuntu 20.04 64bit.

Steps to reproduce

  1. Launch Firefox.
  2. Open a random webpage (non about/local page).
  3. Open a different tab and access the about:support page.
  4. 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

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.

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!

Flags: needinfo?(emalysz)
Whiteboard: [print2020_v85] [old-ui-] → [print2020_v86] [old-ui-]
Severity: -- → S3
Priority: -- → P1
Assignee: nobody → emalysz
Flags: needinfo?(emalysz)
Has Regression Range: --- → yes
Has STR: --- → yes
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
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 86 Branch
Flags: qe-verify+

Moving things to 88, cause we're mostly on Proton these days…

Whiteboard: [print2020_v86] [old-ui-] → [print2020_v88] [old-ui-]
Whiteboard: [print2020_v88] [old-ui-] → [print2020_v86] [old-ui-]

This issue is verified fixed using Firefox 86.0 on Windows 10 64bit, macOS 10.13 and Ubuntu 20.04

Status: RESOLVED → VERIFIED
Flags: qe-verify+

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.

Flags: needinfo?(mstriemer)

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."

FWIW I filed bug 1748846 for this.

Flags: needinfo?(mstriemer)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: