110641 - [UX] ability to print preview in a new tab, so that page is still accessible without reload in original tab

Status: RESOLVED WONTFIX

(Core :: Print Preview, enhancement, P4)

Description

[Jonadab the Unsightly One (Nathan Eady)]

The new print preview is slick.  But Wouldn't It Be Nice If we
could (perhaps optionally) open the print preview in a new tab,
so that the page is still accessible as such (with links and 
so on) without hitting reload?  

Not sure whether a print preview tab should be different from
other tabs, but I suspect maybe it should at least in terms 
of the "Open New Tabs in Background" preference -- a Print
Preview tab should probably get focus (and if possible should
be adjascent to the tab that was showing the page it is 
previewing at the time it was launched, but that may depend 
on bug 105885 and in any case is a minor issue).  

I set OS to All because this is not OS specific, though there 
may be some OSes (e.g. Mac OS X) to which it may not apply.  
But certainly this applies equally to Windows and Unix.  

Some people may want to print preview in a separate _window_,
but if so that would be a separate RFE.  This RFE is about 
the ability to print preview in a tab within the same window
as the page being print-previewed.  

In terms of UI, there are two different ways to let the
user select this:

  1.  Have an entry under the File menu for Print Preview
      in New Tab

  2.  Have an option in preferences (possibly under 
      Navigator->Tabbed Browsing or possibly in a pane
      of printing-related options) to make the regular
      File->Print Preview option open in a new tab.

Given the choice I prefer the latter approach, but 
either will work.

Comment 1

[sujay]

cc: rods.

Comment 2

[rods (gone)]

taking

Comment 3

[rods (gone)]

Yes, we have already discussed this feature.

Currently you can selected the Print Preview mode a second time and go back to 
"galley" mode, except at this time there is a bug in that JS doesn't get 
started.

Also, we anticipate that there will be a toolbar added to the window with PP 
options and a Close button.

The problem with a PP Tab is that the original will need to be "frozen", in 
other words, the PP tab needs to be modal in respect to the original document 
tab. The reason is they both work off of the same document and if script or a 
user was to change the document will PP is up it would cause all kinds of 
problems.

Comment 4

[Jonadab the Unsightly One (Nathan Eady)]

> The problem with a PP Tab is that the original will need to be "frozen", in 
> other words, the PP tab needs to be modal in respect to the original document 
> tab. The reason is they both work off of the same document and if script or a 
> user was to change the document will PP is up it would cause all kinds of 
> problems.

Ah.  So Print Preview needs a frozen copy, and currently it is using
the original.  To allow the user to Do Stuff (TM) with the original
document, Print Preview would need to be altered so that it spawns
off a second (initially identical -- so no going back to the website
or any such chicanery) copy of the page and freezes *that*.  Do I 
have this about right?

Presumably, that would have some impact on performance...  
I have no idea how much, or how difficult it would be, 
because I don't know the data structures Mozilla uses to 
hold web pages in its brain.  

Of course, if it were optional, or if Print Preview only
spawned off the copy in optional cases (such as when the
user chooses to open print preview in a new tab), then
the performance hit would also be optional.  

Comment 5

[rods (gone)]

Yes, that about it. We would need to make a copy of the document in its current 
state. We cannot load it from cache because of how script and the user may have 
changed the document.

Copying the document is always a possiblility, but right now we don't have time 
to implement this.

Comment 6

[Andrew Hagen]

Changing component from printing to print preview.

Comment 7

[Philip Langdale]

Would the page copying code developed for view-source be appropriate for 
producing a copy which could then be switched to print-preview mode? I'm working
on such an implementation in galeon right now.

Comment 8

[Andrew Hagen]

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

Comment 9

[Andrew Hagen]

A related bug is bug 133787.

Comment 10

[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 12

[Steffen Wilberg]

Bug 487667 implemented cloning the document.
This already made print preview open in a new tab. You don't notice because it still hides the titlebar and the navigator-toolbox, and hides all means of navigation. Using DOM Inspector, you can unhide those, and notice what's left to do here:

- Don't hide the titlebar and the navigator-toolbox, but hide the nav-bar, just like the Addons-Manager does.
- Move the print-preview-tooolbar below the nav-bar, and make it only show for the print preview tab.
- Disable the navigational buttons (next/previous/new tab) etc. only for the print preview tab.
- Properly close print preview when closing the print preview tab.

Comment 13

[Jonathan Watt [:jwatt]]

Closing this is favor of bug 133787.