The browser interface should change when entering and leaving print preview mode. The print preview menu option should be checked and unchecked accordingly. There should also be a print preview toolbar with buttons to return to normal, go to page setup, and do any other print preview extras

My guess is that this is a dup of one of pchen's bugs

I tried to find a bug relating to the print preview interface and could not.

Yeah! It looks just like another browser window. I think that the preview should be in a separate window, without the normal Mozilla menus. A Print preview requires a Page Setup, and zoom buttons. What's the reason for showing the back/forward/reload buttons?

Agree, opening the print preview window in a separate window makes sense (in a way similar to what the viewsource mode is doing and this has already stood the test of time). Doing so will solve the confusion of how to get out of that. Also, it will allow UI hackers to chime in and provide other specialized functions (e.g., a Context Menu with "Close", "Print this page", etc). And before I forget, the print preview mode looks great... Try it out with some MathML formulas too!

There's one major difference between print preview and view source. View source acts on the same _source_ as the original document. Print preview acts on the same _content_model_. This is not the same thing when scripts or forms are present. The only way to have print preview be in a separate window is to have the two windows share the same document, as far as I can tell. I'm not completely sure this is doable (easily, with our current architecture). That said, there is no reason the browser chrome can't "mutate" when we go into print preview mode (a la what Word does).

About preview in a new window, see comments in Bug 110641 (which is about printing in a new tab). If I understand correctly, either (printing in a new window or in a new tab) is difficult right now because the print preview needs the document to be frozen (no clicking on links, no triggering javascript events, &c) lest things change out from under the print preview and create an inconsistent state or wild pointers or other dire consequences. This could be solved by having pp duplicate the entire data structure for the document, but at this time print preview doesn't do that. For this reason I suggest that print preview in a separate window be made a separate RFE, because it would be more difficult to implement than what this bug was originally talking about and therefore is unlikely to happen as soon. I think a lot of people would like to see some of the changes expressed in this bug in 0.9.7 or 0.9.8, but I don't think print preview in a new window (or in a new tab for that matter) will realistically make it in quite that soon (though it would be awefully nice if it landed in time for 1.0). Actually, probably there should be two new bugs: one for the ability (as a pref, maybe) to make print preview use a new window, and another (which probably blocks that as well as bug 110641) for the necessary underlying changes -- i.e., make print preview not require the original document to be frozen. Both would be dependencies for the print preview tracking bug.

From what rods said in bug 110641 comment #c5, Clone()ing the document (content model) was considered but was LATER'ed. (From this cloning, the print window could be detached so as not to worry with JS and such, e.g., if a new document is loaded in the originating window -- In viewsource mode too, once launched, viewsource doesn't bother about what is happening in the originating window).

Important different from view source to print preview is, view source doesn't need the document content model or any of that jazz, just the original retrieved source (basically, text), the same thing that would go in the cache (assuming that is enabled). Whatever Javascript does to the window contents really doesn't have an impact on source viewing, for example. If the user fills in a form, that doesn't change the source either. But everything matters for print preview; print preview is like a snapshot of what the page looks like at a moment in time. (Of course, there is the additional complication that it is formatted for paper, which has various implications, but that seems to have already been pretty well worked out.)

It would be nice to have print preview in another window, but that is not really what this bug is about. Since it is in the current window we should change that windows interface to show we are in print preview mode. It could be as simple as adding another toolbar. Just some way to signify I'm in print preview mode and this is how to get out.

re: comment #8, outside the point. I know the differences between the two modes. re: comment #9, fair enough. [but see the pros & cons bug 12111 comment #12].

That comment talks a lot about the end user not caring about page source. There is truth in that, but it is *primarily* the end users who care about print preview. Developers don't print web pages (except to test); they take screenshots. Yes, there are exceptions, but in general it is the end users who print, and it is they who print preview therefore. A "Cancel Print Preview" button would actually go a good way toward the three things mpt says have to be made abundantly clear. A big old picture of a stereotypical printer on the toolbar might not go amiss too, I suppose. It could be labelled "Print This Now" and serve the actual purpose of being a shortcut for File->Print. One bummer would be making this work with themes; I suppose it could default to just the words, and Classic and Modern could have cute pictures of printers and so on.

Pardon me, Jonadab, but I have no idea what you were referring to when you mentioned (but did not list) `the three things mpt says have to be made abundantly clear'. I don't recall saying any such thing. What *is* abundantly clear to me is that print preview using the same content model as the current document is not as important as view source (which opens a new window) using the same source as the original document, and yet we have been putting up with faulty behavior in the latter for years. What is also clear to me is that while print preview itself is cool, showing print preview in the same window as the original page is considerably more embarrassing than not having print preview at all. Until I read this bug I had assumed that showing print preview in the browser window was just a temporary hack to test the preview itself, until a proper UI was developed; I am appalled that it is being seriously considered as a permanent fixture.

Thomas, I am not going to address any "View Source" issues past or present. I am not sure what is so appalling about having the PP render in the same window as the document. Our options for PP are the following: 1) We have to have a "frozen" document, a document where no changes are being made (this is a hard and fast requirement). 2) We can make a complete copy of the complete content model and display PP in the same window or a separate window. With a completely separate document, a separate window displaying PP would not need to be modal. But a non-modal window could be confusing to the user if they make changes in the original window and those changes would not then be reflected in the PP window. 3) Turn off scripting and events and use the current content model. This could be displayed in the current window or in a separate modal window. It needs to be modal because the main window will be unresponsive when it is "locked down". I think it is safe to say we really do no want to make a complete copy of the content model, although for the average document this probably is not very large, but for framesets this could start getting bigger. This is mostly a resource issue. Once we agument the UI so it is abundantly clear to the user that they are in PP, I really don't see much of a difference between having a modal window that pops up (which is what IE on Windows does) and rendering it in the same window (which is what Opera does). (Just to make sure everytone understand: Our assumption all along when considering having PP in the same window is that the UI would make it very clear when the main window is in PP mode. We don't have the UI working yet, so it is premature to judge whether this solution is all that bad)

If I can comment in on the choice between show in same window vs show in modal window... Since all our modal windows are app-modal (not window-modal) on Linux, showing in same window is a _much_ better option there.

I forgot to mention that we trying hard not to do anything that would keep us from showing PP in a separate window.

> I have no idea what you were referring to when you mentioned > `the three things mpt says have to be made abundantly clear Sorry, I misquoted. s/abundantly/very/; I'll list them now: > (1) what mode the user is in now > (2) why the mode exists > (3) how the user can switch to a different mode. Supposing pp removes the navigation-related toolbars (personal toolbar, location bar, document link bar) and replaces them with a toolbar that features the buttons "Print Now" and "Cancel Print" prominently, and some others like page setup and zoom, I think these three things would be adequately handled by that. Eventually, changing which menu options are enabled might also be expedient. But the toolbar changes would be an excellent beginning. > showing print preview in the same window as the original > page is considerably more embarrassing than not having > print preview at all Strong disagreement here. Separate window might be nice, and I hope it makes 1.0, but _having_ print preview is exceedingly valuable for many end users. > I had assumed that showing print preview in the browser > window was just a temporary hack Yes, yes, but let's keep the temporary hack until we have the better feature that's going to replace it working. It is far, _far_ better than no print preview at all. I _mostly_ agree with what rods said in response, also. One minor quibble with that: yes, non-modal would be confusing to most users, but some power users would specifically want the ability to continue to use the page (follow links, use the javascript, edit the forms, and so on) after starting up a print preview. There are a variety of reasons for this, but I'll give just one: I might be ordering something and want to spawn the print preview so I have an unchanging and also printable copy of some part of this process, before proceeding to finish the order. End users mostly won't understand this, so the default should be a modal takeover of the document; but some users, mostly power users, would like the capability, as an option, to do otherwise. Hence the bug about print preview in a new tab; surely someone who doesn't like the tabs will want it in a new but non-modal window also. Neither of these should be the default, however. Boris: > Since all our modal windows are app-modal (not > window-modal) on Linux, showing in same window is > a _much_ better option there. Agree: document-modal is okay, app-modal would be less okay for power users. (Most end users would never know the difference, since they typically aren't aware that multiple windows exist.) I really don't even like window-modal; tab-modal (as it stands now) seems more right, given the presense of other pages in other tabs.

The following trivial comments are based on apps i found on my w2k box. nc4.78, n3.04, n2.02, n1.22 show printpreview in the same window. WordPerfect (7-9) have no print preview in the file menu, instead the view menu has page and twopage (in addition to draft and webpage). StarOffice 5.2 has View>Print Layout, which does not create a new window. After selecting that layout, a File>Page Preview item magically appears. -- This guarantees SO5.2 would not get browny points from mac users (or mpt). OpenOffice build 627 has File>Page Preview, which does not create a new window. Paint Shop Pro 6 has File>Print Preview, which converts the app window from MDI into Print Preview. Jasc Trajectory Pro (0.30 -- sorry i'm a bit out of date) is identical in behavior to PSP6 (makes sense, same vendor...). Feuro Cover Editor (a cd cover maker) has File>print preview>(various things), it too morphs from mdi to print preview. MSPaint (5.0.1523.1 the version that supports import filters, see ARTICLE-ID: Q119591) has File>Print Preview and again it replaces the content. For reference, the MSPaint that ships w/ w2k also behaves the same wrt Print Preview (it just isn't as good w/ filters...) Front Page Express (2.0.2.1131) has File>Print Preview, and again it replaces the mdi content. CuteHTML's File>Print Preview has a tablist at the bottom so you can preview any of your open documents, but you can't edit anything until you leave Print Preview. <- this is an interesting interpretation. Write's Print>Preview is like navigator et al. IE5.5's window modal sizable print preview window sticks out like a silly and useless sore thumb. Can someone please explain to me how i benefit from ie's impl? -- As for view-source opening in a new window, nc4 can actually sometimes browse inline.

timeless, Thanks for the recap on several apps that is very helpful (at least from a Win perspective.) My "take away" on this is that taking over main window should not seem strange to the average user. I agree with your comment about IE impl and I don't see how implementing ours as a separate modal window would be a whole lot different. Also, for Mac users we plan on using the OS PP on Mac OSX. As to Jonadab's comment about removing the a bunch of the UI, or replacing a bunch of the UI, I don't see that happening. I see us merely adding a simple PP toolbar and then removing it when the user is done with PP. As a user I don't want to lose a bunch of my UI, maybe I want to go directly from PP to Bookmarks or hit the Back or Forward btns. I am not trying to end this discussion, but the reality of it is that we just don't have the resources at this time to go down a different path. Take a look at my bug list and then you will understand the following comments: 1) We will not be creating a separate document any time soon a) There is no easy way to do this today, although it probably wouldn't be too difficult to write the routine that copies the DOM tree, it is just all the rest of the stuff that is hard to coordinate and get right b) It is a resource issue, we really do not want to take up even more resources for PP 2) I just don't see us creating PP as a separate window any time soon a) This means either sharing the same document, which means the main doc is modal, which seems too much like IE's hokey impl. b) We could create a separate doc (see item #1) 3) Some of Boris's concerns about the UI are reasonable, but beyond that I just haven't heard a compelling argument that would justify a lot of extra work. When you balance features vs cost; at this time, on this project, with these resources, I am afraid this is about as good as it gets. (there are so many other things to fix with PP right now) This discussion IS worth having for getting ideas about what to do in the future when we do have the time or the resources to "improve" on what we have. I, myself, would rather have PP clipping the contents of the Window correctly than have a separate window popping up :)

This might not be the best bug to ask this in, but would the following be possible: 1. Print Preview under the Print menubutton 2. Checkmark indicating Print Preview mode

1. bug 111126 2. This bug.

my .02 cents on this issue. I looked up this bug because I saw a significant break in workflow... print preview is not a feature in and of itself, it is an extention to the feature of printing. Print Preview -> Print or Print Preview -> Back to Browse should be the main paths here. There needs to be a new additional widget somewhere that gives the user this choice after selecting print-preview. Printing should be 1 click away after Preview, you shouldn't have to select another menu option. I've always hated the new window way of doing this, it is great for developers, bad for normal users.

I have a suggestion, about the PP toolbar. It should be on the right of the sidebar below the tabs ie inside the content frame (see bug 97023 and bug 102990 for bugs in which such a class of toolbar would be helpful) In this toolbar, there would be options like: - fit in page button - zoom droplist (+text field) - a "Set up" button - extra... - and... a close button the "Print Setup" button would call the window moved from "print>properties" (by Roland Mainz) to specify the margins, grey/color, landscape/portrait, page type. Changing the setup would update the print preview lay-out. Time to create a new class of toolbar should be evaluated. Maybe it is unrealistic.

> I have a suggestion, about the PP toolbar. > It should be on the right of the sidebar Realistically, there is not, on a small (15" viewable 640x480) or medium (800x600 16" viewable) sized display, enough space to have the sidebar visible (well, at any useful width) and still show the whole width of the page at a useable scale. Print preview is really only any good if you can show the whole width of the page (zooming aside), and you don't want to scale it down any more than is necessary, because it makes it that much more difficult for the user to actually see what is where. Remember that many users use pp to determine which page range they want to print, by looking for where certain text appears; to do that, they have to be able to read the text. You don't want them to have to zoom in two or three times to do so, because then they end up scrolling horizontally to find what they're looking for. Especially on pages with extra table-based stuff (adverts, menu, whatever) on the left, which is common. So, I don't think the sidebar is a good solution for the print preview UI, on the grounds that the user may need to close the sidebar for print preview to be properly useable on a small or medium-sized display. Then there are the not-insignificant portion of people who keep the sidebar closed all the time. I do not know how much overlap there is between these people and those who use print preview. Probably less than a proportional slice, but still something to consider.

Jonadab, I don't see your point. If the screen is too small, just hide the sidebar and in this case, the (horizontal) PP toolbar would be under the browser tabs. see bug 102990 for further discussion.

My $0.02: On build 2001121103, Win2K SP2, selecting Print Preview replaces the page I'm viewing with the preview, and there is no obvious way to return to the previewed page. More interestingly is that if I then select Print View (while in the Print Preview) I return to the original page. First, I did not expect to see Print Preview active in the menu while viewing a print preview, and certainly did not expect that item to take me out of print preview. Simply stated, my huge problem with print preview is that it removes (or appears to remove) my access to the "original" page, period.

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

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

There are UI bugs files on this already, so I am going to mark this won't fix.

verified.

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

Reopening. I don't see an open bug on this issue. If there is please dupe this against that bug. Thanks.

missed that radio button I guess.

Reassigning to law@netscape.com. According to rods, Bill is working on the print preview UI. I couldn't find an existing bug on Bill's list for print preview

Samir has print preview.

Taking for mozilla0.9.9.

law, please r. hewitt, please sr.

Reviewers, please have a look at this patch instead. Thanks.

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

updating summary

Comment on attachment 69901 [details] [diff] [review] Same patch as above now with *all* files including missing css ``linkage''. r=law Looks great, Samir. One minor issue: It looks like your Portrait and Landscape toolbar buttons have hardcoded labels. Shouldn't those be localized (.dtd entities)? Once that issue is resolved, then it the patch is OK by me.

Comment on attachment 70424 [details] [diff] [review] Revised with strings moved to a dtd. Crap. I added the wrong patch! Adding the right one now...

Comment on attachment 70466 [details] [diff] [review] Move image URLs into CSS and other style-related changes per hewitt. sr=hewitt

Checked in.

on linux, clicking "landscape" button i get a crash. $prog ${1+"$@"} Status Information: sending job 'dark2@localhost+549' to missingprinter@localhost connecting to 'localhost', attempt 1 cannot open connection to localhost - Connection refused Make sure LPD server is running on the server Status Information: sending job 'dark2@localhost+550' to missingprinter@localhost connecting to 'localhost', attempt 1 cannot open connection to localhost - Connection refused Make sure LPD server is running on the server [1]+ Exit 139 ./mozilla I have no printer set up, i was just curious about how it would lay the page out. But it seems clicking actually tried to start a print? I got the same error msg ("sending job to...") but no crash, when later clicking the "close" button.

I may be in the wrong bug, but a fresh CVS build build ow tells me that i need a printer configured to use print preview. And then i crash.

New print preview has landed....its a toolbar now... verified in 2/20 build. dark/RAka, please file a new bug for the issue you are experiencing having to do with "i need a printer configured to use print preview. And then i crash."

If the Link toolbar (Site Navigation Bar) is set to "Show Always" then its shown in the print preview mode. Is this by design or is this a bug? It should be a bug IMO.

Trivial search on "print preview toolbar" shows bug 126664