Open Bug 1746922 Opened 2 years ago Updated 11 months ago

Print Preview Dialog should not be dismissed by page navigation

Categories

(Toolkit :: Printing, defect)

Desktop
All
defect

Tracking

()

People

(Reporter: mgaudet, Unassigned, NeedInfo)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [fidefe-quality-foundation])

So, I was on an e-commerce site and made an order. While looking at the order confirmation page, I had to step away from my computer.

When I returned, I went to print (to PDF) out the order confirmation page. While the print preview dialog was shown, the page decided to navigate me to the login page -- some sort of session log out I imagine.

This dismissed the print preview, and meant that I lost the ability to save the PDF.

In my opinion: Print on a page should either block navigation, or at the very least not dismiss the print dialog and preserve the contents.

Component: DOM: Navigation → Print Preview

Yeah, that's a pretty frustrating user experience. Some time ago we used to prevent script from running in the original page which would prevent it from navigating. We stopped doing that, in part because stopping script running for a prolonged period of time in the original page could cause it's own issues (such as timeouts in script the original page). Since that then allowed a print preview's original page to navigate while the print preview is up, we then had to decide whether to allow the page the user is returned to to when the print preview closes to have changed (which could be confusing), or whether we should cancel the print preview on navigation so it doesn't get out of sync. In the end the cancellation happened basically by default when we enabled the new, tab-modal print preview UI, just due to the mechanism it uses (see bug 1657508). Whether we should prevent navigation or whether we should close the print preview (or do something else) is a UX question, though, and I don't think we ever got an answer from UX on that. Certainly our current behavior should be up for revisiting, I think.

Regressed by: 1657508
Has Regression Range: --- → yes
Component: Print Preview → Printing
OS: Unspecified → All
Product: Core → Toolkit
Hardware: Unspecified → Desktop
Summary: Print Dialog was dismissed by page navigation → Print Preview Dialog should not be dismissed by page navigation
Version: unspecified → Trunk

Romain, we had made a conscious decision to close this dialog on navigation, but as mentioned in comment 0 this can cause issues when the user wanted to print the page that navigated away.

What do you think we should do here? Does this seem like an issue that we should revisit our decision on?

Flags: needinfo?(rtestard)

Print is a pretty strong user decision which in my opinion should be higher priority than running scripts on the page you're attempting to print - as a user I'd expect the page print-out action to be more reliable than a script execution on a page (which I could most likely re-run post printing if timeout occurred by reloading the page or achieving an action on the page).
I think we should revisit the decision so that navigation is prevented and print action in completed in this instance - this although does not feel like a high severity - I think S3 is the right severity for this bug.
I NI Aaron in case he has objections on this decision from a UX standpoint.

Flags: needinfo?(rtestard) → needinfo?(abenson)
Severity: -- → S3
Flags: needinfo?(fchasen)
Whiteboard: [fidefe-quality-foundation]
Flags: needinfo?(fchasen)
You need to log in before you can comment on or make changes to this bug.