This is UE. It's an offshoot of bug 132464. Currently, when we get a close window request from print preview, we restore the window to browser mode and then don't close the window. This can be confusing to users, and even a little frustrating. If you are used to closing windows by clicking the upper right hand corner X, as in the Win32 GUI, for example, then you expect all windows to close as a result of clicking that X, or by using the function that you normally use. There's a good reason why we don't close the window, however. If we don't restore browser mode, we could create dataloss. The design should be changed. The close button in the print preview bar should still restore browser mode and keep the window open. Other close commands, however, should automatically restore browser mode, and then close the browser window in one complete operation. This would mirror the behavior of other applications that have a print preview, such as Microsoft Word. It would also be more consistent with what we usually do with a close window request.

this is as designed. we have no choice but to prevent dataloss in this situation, so we cannot close the window. think of it this way- if PP were it's own window, it would still take two close window operations to close both the PP window and the browser window, if that' s what the user desired. with our current design, you still must perform those two close window operations. we have both the safest and more reasonable solution given the implementation.

Couldn't we use the close window command to do two things, one after the other? Couldn't the close window request first restore browser mode, and then, once that is complete, automatically close that browser window? Wouldn't that prevent any dataloss? Thanks.

if i understand what you are saying, that's still losing data. there's no technical hurdle to closing the window -on the contrary we don't close it because the user intent may not be to close the browser window.

The user intent in Win 32 when you hit Alt-F4 or click on the upper right X box is to close the window. That's always the expected behavior. The only time the window doesn't automatically close is when it asks you for confirmation, or to save your data. Let's say you're working in notepad. You type something, then hit Alt-F4. It will ask you if you really want to discard your work. What is the potential data loss? If the only data that we would lose would be stuff typed in a textbox on the page, a user should expect to lose that if they close the window. If they just want to restore browser mode, and not close the window, they should use "close" on the print preview bar. That's the more common practice on other Win 32 apps, anyway. Maybe I'm taking too much of a Windows-centric approach here. Thanks.

1. you aren't taking a windows centric view. 2. you're absolutely missing marlon's point (which is also at least a semi valid windows view) 3. you're essentially asking us to force print preview to a be window modal window taskbar hidden window just to maintain this feature -- which is what IE5.5 does. What precisely do we gain by making this change? A quick check, we gain an extra window which isn't listed in the taskbar, we gain the ability to drag that window away from the real window and click on the real window, resulting in beeps because we can't click in the real window. Please write up a useful proposal to be discussed in a newsgroup or by pixeljockeys. please take into account at least: ie5(win), msword (2 current versions), wordperfect (1 recent version), adobe acrobat reader (4 and 5), and three other major applications for windows.

I raise this issue in good faith and honesty. I don't mean to hassle you guys. We're all really busy right now. We could just drop this until the 1.0 release, for example. Maybe I am missing Marlon's point, and yours, but that is because I don't understand them. The only reason for making the change would be consistency, at least on the Win32 platform. No other Win32 application *ever* takes a window close command (like Alt-F4) and keeps the window open, unless the user is prompted with a "are you sure?" message and cancels the window close command. But that is exactly what Mozilla is doing in print preview mode. So in answer to your question of what do we gain, the answer is consistency with other Win32 apps. The data loss seems to be non-existent. Thus, there doesn't seem to be any reason to keep the existing behavior.

> No other Win32 application *ever* takes a window close command > (like Alt-F4) and keeps the window open, unless the user is prompted with > a "are you sure?" message and cancels the window close command. But that > is exactly what Mozilla is doing in print preview mode. So in answer to > your question of what do we gain, the answer is consistency with other > Win32 apps. Errr, have you tried IE 6.0? It does exactly what we do in the following cases: (1) clicking the button entitled ``Close'' on its print preview toolbar (2) clicking the `x' close button on the right hand side of the window titlebar (3) pressing the alt-F4 key combination That is, they all drop you back into ``browse'' mode from ``print preview'' mode. > The data loss seems to be non-existent. Thus, there doesn't seem to be > any reason to keep the existing behavior. I think if a user lost form data even *once* they would potentially be rather turned off by the client. That is, if they are filling a form (or a Java web app's text widgets for example) and we destroy the window they could potentially have lost their information. I simply must agree with what timeless said in comment 5 paragraph 3.

Point taken regarding the user's experience with data loss. I'm using IE 6.0.2600 on Windows 98. There, print preview opens a new window. Alt-F4 closes that new window. Unlike Mozilla, in IE 6, using Alt-F4 on the print preview window no no effect on the parent window. If we implemented print preview in a new window, like IE 6 does, my concerns would be completely alleviated.

> If we implemented print preview in a new window, like IE 6 does, my > concerns would be completely alleviated. Constrained by the backend. I think that's what Marlon meant in comment 1: ``... more reasonable solution given the implementation.''

Now I get it. Thanks. It seems like what I am asking for is to implement print preview in a new window. That would make this bug invalid.

OK, so file a bug against the ``Print Preview'' component for the above request.

Resolving invalid. I'll open a new bug.

Spam. The followup bug is bug 133787. Endspam.

Hang on a minute! Shouldn't we reopen this bug? I disagree with marlon (comment 1 in particular) because I have seen that if you have a really non-standards-compliant document or a web "page" that is actually thousands of pages long, the PP engine may seem to "hang" for ages while it is generating the preview. Of course, the user will get impatient, and instinctively click the "X" on the PP "popup". Then the OS will say that Mozilla is not responding and the whole browser will die, killing the user's session (which may consist of many tabs). Of course, PP should not steal focus from the browser's main window in this way. Instead, it should steal focus from the tab which contains the page that the user is attempting to preview (to stop the user doing things to the page/changing the website while the preview is unfinished). PP would be nice if it was a kind of floating list box that showed every PP task that was requested. You could reuse the interface for the "Downloads" dialog box and change the titles/remove a few unnecessary elements. It would also be nice if the final print preview window allowed to select between multiple documents as they finished processing (except the first, which would trigger the opening of the output window). To enable this behaviour, "File -> Print Preview" should be bound to the current tab the user is viewing.

No. Asking for multiple print previews simultaneously, where at least two of them take a long time, is such a rare event that a separate window listing them would be much more annoying than useful.

Backtrack. OK. Carry on as usual, allowing one PP operation at a time but lock them onto the tab in which they are being carried out so the user can browse in other tabs while PP is building in background if boredom makes this a requirement.