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

NEW
Unassigned

Status

()

enhancement
P4
normal
18 years ago
2 years ago

People

(Reporter: contact2009, Unassigned)

Tracking

(Blocks 4 bugs)

Trunk
Future
Points:
---
Dependency tree / graph
Bug Flags:
firefox-backlog +
blocking1.9 -
wanted1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: p=0)

Attachments

(1 attachment)

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.
Status: NEW → ASSIGNED
Priority: -- → P4
Target Milestone: --- → Future
Keywords: mozilla1.1
This bug conflicts with bug 110641. 
Keywords: mozilla1.1mozilla1.2
*** Bug 172769 has been marked as a duplicate of this bug. ***
<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....
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".
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.
nsbeta1-
Keywords: nsbeta1nsbeta1-
*** Bug 262574 has been marked as a duplicate of this bug. ***
mod summary
Assignee: rods → printing
Status: ASSIGNED → NEW
QA Contact: sujay
Summary: implement print preview in separate window → implement print preview in new separate non-modal (modeless) window
Blocks: 111935
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).
Blocks: 369590
Flags: blocking1.9?
No longer blocks: 369590
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: printing → nobody
QA Contact: printing
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.
Blocks: 616843
One idea is listed in bug 122126, which appears to have stalled.
Blocks: 59314
No longer blocks: 59314
Blocks: 177491
Posted image Possible solution
This could be a solution to the problem.
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(!)
Duplicate of this bug: 850832
Blocks: 947125
Whiteboard: [feature] p=0
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].
No longer blocks: fxdesktopbacklog
Flags: firefox-backlog+
Whiteboard: [feature] p=0 → p=0
Summary: implement print preview in new separate non-modal (modeless) window → [UX] Implement print preview in new separate non-modal (modeless) window
Summary: [UX] Implement print preview in new separate non-modal (modeless) window → [UX] Make print preview tab-modal instead of window-modal
Duplicate of this bug: 615349
See Also: → 122126
Summary: [UX] Make print preview tab-modal instead of window-modal → [UX] Redesign print preview and make it tab-modal instead of window-modal
Duplicate of this bug: 1385689
Duplicate of this bug: 1400305
See Also: → 650966
Summary: [UX] Redesign print preview and make it tab-modal instead of window-modal → [Meta][UX] Redesign print preview and make it tab-modal instead of window-modal
Blocks: 1302489
Summary: [Meta][UX] Redesign print preview and make it tab-modal instead of window-modal → [UX][Meta] Redesign print preview and make it tab-modal instead of window-modal
You need to log in before you can comment on or make changes to this bug.