1659624 - Close the new print UI after the user clicks the "Print" button (or after "Save" for Save to PDF)

Status: VERIFIED FIXED

(Toolkit :: Printing, enhancement, P1)

Description

[Jonathan Watt [:jwatt]]

Users probably don't want to have to click the "Cancel" button after clicking the "Print" button in order to close the doorhanger. It should really close automatically (this is what Chrome does FWIW).

The wrinkle here is that, as currently implemented, the doorhanger needs to stay open long enough for the print to complete, otherwise the print preview document could be killed mid-print. To eliminate the need for that, the platform code should probably clone the print preview document into a hidden tab, print from that, and auto-close that tab itself.

Comment 1

[Sean Voisen (:svoisen)]

This seems like a must-have for shipping (it's a very awkward experience without it), and sounds like the majority of the work rests on platform.

Comment 2

[Jonathan Watt [:jwatt]]

Sean and I discussed this, but just in case it isn't clear for others, I filed this against Toolkit and only mentioning the possible platform work to improve things for completeness. I don't think the change in behavior requested in this bug requires the platform work (that's a UX question though), and in any case I don't think we can do the platform work in the v81 beta timeline. However, the implementation details of that platform work would be closely related to Emilio's window.print work, so Emilio should correct me about that if he thinks it's possible (I think it would involve creating and cloning to a hidden tab that the platform code would automatically close itself after the print completed).

Comment 3

[Emilio Cobos Álvarez (:emilio)]

Why would creating a new hidden tab of sorts be required? So, platform should have the capability to notifying at the appropriate time, I think. And I think we already do that.

Right now when you schedule a print of the print preview document we actually create a separate print object with separate clones which are kept alive separately as well, by the content viewer etc. So I think that should mostly just work.

We of course need to change this setup to avoid recloning so much (that's effectively bug 1636728), but I don't think the document dying mid-print is a concern here? What is not being kept alive properly right now Jonathan?

Comment 5

[Martin Balfanz [:mbalfanz]]

Attachment: Screenshot 2020-08-21 at 09.00.44.png

Just bumped into this and I agree that this is a must have. Currently, the user has no feedback if the print was successful or not. If the dialog remains open, that seems like something went wrong. However, if I hit "save" again (in case of saving to PDF), I get the error "Some printing functionality is not currently available" (see screenshot).

Comment 6

[Jonathan Kew [:jfkthame]]

(I was about to file a bug on this same issue, as it felt really strange to me.)

I think that when the Print or Save action is clicked, the dialog should ideally remain open, with a progress spinner running in the middle of the preview pane and the Print/Save button disabled, until we've finished processing the job (which doesn't mean the printer driver is done with it, it may still be queued), and then the dialog should go away. That would give the user feedback (for non-instantaneous jobs) that something is happening, which we currently seem to lack.

FWIW, I tried clicking Cancel to dismiss the dialog immediately after starting a really large (800+ pages) Save as PDF job, and also closed the tab, and the job still seemed to complete just fine.

Comment 7

[John]

I also just ran into this issue, but with the system print dialog. After printing a page by going into the tab-modal dialog, and then clicking through to the system dialog and printing there, the tab-modal dialog remained open. In my opinion, it should also close in this case, at least where printing has been performed.

Comment 8

[Sean Voisen (:svoisen)]

(In reply to John from comment #7)

I also just ran into this issue, but with the system print dialog. After printing a page by going into the tab-modal dialog, and then clicking through to the system dialog and printing there, the tab-modal dialog remained open. In my opinion, it should also close in this case, at least where printing has been performed.

Preferably, the tab modal dialog should close immediately upon opening the system dialog (at least this is what we had written down in our original requirements). So I've filed bug 1660665 for that.

Comment 9

[Jonathan Watt [:jwatt]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #3)

Why would creating a new hidden tab of sorts be required?

If the doorhanger goes away, then so does the docshell parent for the new UI's print preview browser. Since we currently hang the print static clone for final print off that same owner, it will lose its owner as soon as the doorhanger closes, and it seemed likely that might do bad things. Maybe I'm wrong. But that was my thinking as to why we'd need to create a hidden tab to own the final print document in order to immediately close the doorhanger when the user hits the Print button.

Comment 11

[Emma Malysz]

Attachment: Bug 1659624, close print UI if user submits the form.

Comment 12

[Phabricator Automation]

Comment on attachment 9171828 [details]
Bug 1659624, close print UI if user submits the form.

Revision D88096 was moved to bug 1660665. Setting attachment 9171828 [details] to obsolete.

Comment 13

[Emma Malysz]

Attachment: Bug 1659624, hide dialog box when the user submits form

Comment 14

[Phabricator Automation]

Comment on attachment 9171828 [details]
Bug 1659624, close print UI if user submits the form.

Revision D88096 was moved to bug 1660665. Setting attachment 9171828 [details] to obsolete.

Comment 15

[Emma Malysz]

Attachment: Bug 1659624, close the print UI when the user chooses to print or save

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb774bb37ac2
close the print UI when the user chooses to print or save r=mstriemer

Comment 17

[Emma Malysz]

Comment on attachment 9173733 [details]
Bug 1659624, close the print UI when the user chooses to print or save

Beta/Release Uplift Approval Request

• User impact if declined: The printing experience will not be great, and the user will have to cancel the dialog themselves.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Open firefox with print.tab_modal.enabled turned on

2. Print a page
3. Notice the print preview window closes

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): No string changes
• String changes made/needed: n/a

Comment 18

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/bb774bb37ac2

Comment 19

[Jonathan Watt [:jwatt]]

Until bug 1636728 and the other platform patches that build on top of that bug are uplifted, this may behave badly on Beta.

Comment 20

[Jonathan Watt [:jwatt]]

Looks like we're uplifting those now.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9173733 [details]
Bug 1659624, close the print UI when the user chooses to print or save

Approved for 81.0b6.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/b0927caac6ae

Comment 23

[Vlad Lucaci, Desktop QA (:vlucaci)]

Hello,

Confirming this as verified fixed on 82.0a1 (2020-09-20) and 81.0 - pref'd on. Confirmed using Windows 10x64, macOS 10.15 and Ubuntu 20.