133787 - [UX][Meta] Redesign print preview and make it tab-modal instead of window-modal

Status: RESOLVED FIXED

(Toolkit :: Printing, task, P1)

Description

[Andrew Hagen]

This is an offshoot of bug 133388. 

There are some user interface problems created by using the browser window for
print preview. Window close commands lose consistency with other applications
common to the platform. For example, Alt-F4 on Windows usually closes the
window, or asks the user if they want to save their work before closing the
window. In Mozilla's print preview, however, Alt-F4 appears to do nothing.
Another example is clicking the upper right-hand "X." This usually has the same
effect in Windows as Alt-F4. In Mozilla's print preview, however, it restores
browser mode, and keeps the window open.

The current implementation does not close the Window when the user clicks on the
upper right-hand "X" because the user may have typed data into a form, and that
would be lost if the browser window were closed. That problem could be avoided
by implementing print preview in a separate window.

IE 6 implements print preview in a separate window. That isn't a reason for us
to do so, of course.

For the sake of window closing behavior consistent with the platform, we should
implement print preview in a separate, non-browser window. The user can close
that window with Alt-F4 or by clicking the "X" and not have any dataloss issues.

Comment 1

[Andrew Hagen]

This bug conflicts with bug 110641. 

Comment 2

[Boris 'pi' Piwinger]

*** Bug 172769 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Ruppel]

<exerpt from my bug>
This behavior is so strange, you even have to implement a button that says
"close" so that users will kind of know what to do, although even that is a leap
of faith.  Why would close be the command to use to get back to the web page I
was just at?

Moreover, the print preview window is completely different from a standard
browser window.  There is no indication that this window is actually the window
you were just browsing with in disguise, and that hitting "close" won't just
discard this window along with your browser window which is already gone...
which must be a bug....

Comment 4

[rods (gone)]

To PP in a Tab or in a new window will require copying the document. Because PP
(and printing) use the current document and turn off script etc. You can't have
two views of the same document and allow one of the views to update the document
while the other assumes the document is temporarily "frozen".

Comment 5

[Ben Ruppel]

Okay, so it seems to me that the solution would be a dialog-box type setup (like
what happens when you get a page load error), where the print preview comes up
in front of the original view and freezes it until you close the print preview
window.

Comment 6

[Kevin McCluskey (gone)]

nsbeta1-

Comment 7

[Adam Guthrie]

*** Bug 262574 has been marked as a duplicate of this bug. ***

Comment 8

[Wayne Mery (:wsmwk)]

mod summary

Comment 9

[Alex Tanner]

Unfortunately, not putting "print preview" and "print" dialogs in the background also creates the following problem. Try "print preview" on this page for instance. http://samuel-beckett.net/Waiting_for_Godot_Part1.html
As you can see, the browser stops responding when there are too many pages in the document. Clicking the "X" on the progress dialog just pops up an "End Task" window and nothing further can be done in the browser (Firefox 1.5.0.4 on Windows 2000 tested).

Comment 10

[Marcelo Bastos]

This would solve Bug 177491, which is VERY old -- reported back in 30 oct 2002, and still a problem in Seamonkey 1.1.16 and Firefox 2.5rc2.

Comment 11

[imradyurrad]

So what's the state of this bug? Can't go unchanged forever.

Comment 12

[Roman]

One idea is listed in bug 122126, which appears to have stalled.

Comment 13

[Joel Linn]

Attachment: Possible solution

This could be a solution to the problem.

Comment 14

[Joel Linn]

The print preview as it is today is a remnant of the no tabbed browsing era. So I think it would be best to allow it to be showed per tab. This would fix a dozen of user interface inconsistency problems.

Something has to be done because this UI flaw is now around for OVER A DECADE(!)

Comment 16

[Steffen Wilberg]

Chrome has a very nice print UI, which combines the print dialog, page setup dialog and print preview into a single tab-modal sheet, see bug 650957 attachment 8373015 [details].

Comment 21

[Jonathan Watt [:jwatt]]

I dup'ed bug 650966 to this bug since there's a bunch of noise in the comments over there that at this point aren't really useful. The one comment potentially worth considering is bug 650966 comment 1:

This is vastly easier now we clone documents for printing.

I've had some ideas for this rattling around for a while.

My main idea is to get rid of the print-preview mode for layout
presentations. Introduce a new XUL <page> element that can reference a print
presentation and render a page from that presentation. Implement print
preview by creating a print presentation and constructing a list of XUL
<page> elements rendering its pages. Then with straight XUL you can do all
kinds of things we can't do today, like add per-page UI, preview N pages at
a time in any layout, visually select pages to print, direct-manipulation
changes to margins, use whatever style you want, etc. Would also simplify
layout and provide better WYSIWYG guarantees since the same presentation
would be used for print preview and printing.

Comment 22

[Scott]

So where are we with this issue? There seems to be three of them very similar: 219412, 347417, and 133787. These have all been open for over 15 years!

From my understanding Firefox used to have a built in print preview function on Mac's but then removed it since OSX added their own. However macOS no longer has a built in print preview (except for Apple's own apps) so wouldn't it make sense for Firefox to re-enable their own print preview function again?

I have tried tons of "print preview" add-ons for Firefox and they all seem to be built off the same framework which doesn't work all the time. Before printing I always invoke the preview to I can ensure text/page elements all fit on the page correctly and often times it's best to shrink the scaling % to fit better. For example, that one line that always seems to get put on page two, but changing to 90% and then everything fits on page just fine. Even when I get the preview looking right and hit print, I'm then presented with different options (auto shrink page width, print background images, paper orientation, etc) and these settings seem to be a gamble since they never seem to match what I just saw in the preview. One common problem I have is looking at the preview which is in portrait, but when actually printing it comes out in landscape. Or trying to match up the scaling % in both places. It's kind of like having two volume controls on a Bluetooth speaker....do you set one to 100% and then adjust as necessary with the other, or mix the two controls until you get what you want? What's worse is you'll never know until you actually print it out to see if it worked. Most of the time this leads me to printing 5 or 6 times or exporting as a PDF and THEN printing just to get it to come out right.

Rather then having this headache any longer, why not build in a print preview into Firefox so that the printing process is one step like it is in other browsers? I click print, I get a preview window, adjust if needed and then confirm the print and be done. This is lot more straightforward then having to use a 3rd party preview system that frequently does not match Firefox's print settings which results in incorrect print jobs and wasted ink and paper.

Comment 24

[Mark Striemer [:mstriemer]]

Updated UX mocks https://mozilla.invisionapp.com/share/MFWMR6H5X3K

Comment 27

[Romain Testard [:RT]]

[Tracking Requested - why for this release]:

Comment 28

[Julien Cristau [:jcristau]]

Can you clarify the intent of the tracking request for 82?
Tracking meta bugs tends not to be very actionable as it's hard to know the status, with many dependencies of different severities.

Comment 29

[Romain Testard [:RT]]

(In reply to Julien Cristau [:jcristau] from comment #28)

Can you clarify the intent of the tracking request for 82?
Tracking meta bugs tends not to be very actionable as it's hard to know the status, with many dependencies of different severities.

This is part of the experimenter signoff process per https://mana.mozilla.org/wiki/display/FIREFOX/Pref-Flip+and+Add-On+Experiments#PrefFlipandAddOnExperiments-Bugzillaupdated

Comment 30

[Julien Cristau [:jcristau]]

Ah, I believe that's talking about the experimenter bug not this one.

Comment 32

[Daniel Holbert [:dholbert]]

This project (tab-modal print preview dialog) has shipped a year or so ago, so let's close this meta-bug.

(There are still some open dependencies which we can track individually, and still group under this umbrella, but having this metabug open doesn't serve much purpose at this point.)