User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 Mozilla is setup as by default browser for Windows (hey, it's a great browser!). If I click on a URL link in Windows, this causes Windows to (normally) load the URL in the most recent Mozilla window. If that window happened to be in Print Preview mode, the new URL gets loaded into that window, which has all of the print preview icons, etc., and none of the regular navigation toolbars, etc. Reproducible: Always Steps to Reproduce: See Details - it's pretty straight-forward. Actual Results: See Details. Expected Results: Mozilla should change the "active" window to a "normal" (not Print Preview) mode, and then load the new URL. I'm using the theme Orbit #-1 1.2 0.0.6.4-dev.

The print preview window takes the place of the normal browser window. Print preview should open in a separate window that does nothing but display the image to be rendered by a printer. No drag and drop, no active links, just a display. If this were the functioning of the print preview window, a new page being loaded into the browser wouldn't touch the print preview window.

Sorry. I see that my comment above is about the same as Bug #133787.

->print preview

Reporter: The build in which this bug is reported against is very old. The problem may have already been fixed. Could you please download a recent nightly build from <ftp://ftp.mozilla.org/pub/mozilla/nightly/>, and then let us know if you still see this problem? You wrote, "If I click on a URL link in Windows, this causes Windows to (normally) load the URL in the most recent Mozilla window." Which URL link is one supposed to click? I've tried clicking a Favorite item from the Start menu, but it always opens it in a new Mozilla window. Thanks.

I am no longer able to convinve Windows to open links (like from an email message) inside an existing Mozilla 1.6 window (even though advanced.system.supportDDEExec pref is set to True). I am, however, able to get Windows to open links inside an existing Firefox 0.8 window. And I just confirmed that this problem still exists. If you're in Print Preview mode, and that window gets "reused" to open a new link, the page loads inside the Print Preview mode, and you cannot click the "Close" (close print preview) button. You're forced to kill the window. So, it's still there!

Could this be a Firefox-specific bug? I couldn't reproduce it in Mozilla. When I try to open a link from, say, a mail window while the browser window is in Print Preview mode, the following message would appear: "The document cannot change while Printing or in Print Preview." Arguably, this is the desirable behavior. Confirming and moving to Firefox.

This also happens on XP (as expected)

I had a similar experience with firefox 0.8 on Gentoo Linux. Doing a refresh (via F5) in print preview mode caused it to stay in preview mode as the others have indicated.

I was about to open a new bug report but this thread seems to be the best place for it. I've found that while in Print Preview in Firefox 1.0PR on Windows XP (Service Pack 2) if I press F5 to reload the page I get the page rendered without any relevant media="print" stylesheet, and the "Close" button no longer works so I can't return to the normal view. I have to close the browser and start again. You can test this as follows: navigate to any URL that includes a print stylesheet, e.g. http://www.b3ta.com; go to File | Print Preview; hit the F5 key; watch as the background colours re-emerge; try clicking "Close" and observe how nothing happens!

I've noticed similar behaviour in the most recent nightly build of Firefox 1.0 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050113 Firefox/1.0+, downloaded on 14.01.2005) If I open the print preview window (which now is the most recently active Firefox window) and in another application I click an url - Firefox as my default browser tries to load the page. Then, alert "The document cannot change while Printing or Print Preview" and it's ok. But, when I actually print the page on printer but don't close the print preview window and once again click the url in another application, Firefox loads url (requested page) into print preview window. Moreover - I may click 'close' button and I see my tabs :) I may also open/close new tabs etc. But the print dialog buttons are still on the top of the window.

The same faulty behaviour as in comment #10 can be observed by clicking "cancel" button during prinitng (in 'print preview window'). After clicking 'close' button (close print preview) the same error occur.

Still a problem in 1.0.4 I have firefox set: Open links from other applications in: A new tab in the most recent window Force Links to open in: A new tab 1. Open a page, goto print preview 2. In another application (such as mirc) Open a link (in mirc, double click) Firefox brings the tab bar into view, opens the new tab as normal - only, there is no address bar, menu bar etc - just the print preview stuff. All tabs function as normal, links work etc. Close button has no effect I have to close the window and restart FF to get my normal view back.

If you refresh(F5) the page while viewing the print preview, it will also load the page inside the print preview window.

Thios problem also occurs if you refresh a page whilst in print preview, you can then not get out of that view without closing firefox / all open tabs etc.

I´m using Firefox 1.05 If in print preview, and right click mouse and select RELOAD, then the page get reloaded, but there is no address bar, menu bar etc - just the print preview stuff. All tabs function as normal, links work etc. Close button has no effect. The only way out is to close the window and restart FF to get my normal view back.

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

I'm using Fiefox 1.0.6, the error still occurs. When this occurs, the top menu can only be closed if you return to the tab that generated the preview and then close the preview window. Trying to close this menu clicking the "close" button in another tabs doesn't work. Clicking this button two things can happen: or it will cause nothing; or it will hide all the tabs! Changing the tabs could be possible pressing CTRL+TAB, but to "unhide" (show again) the tabs, it can be done while pressing CRTL+T. So, the only way I've found to close the top menu is to return to the tab that has generated the preview, and then there will be the preview's window, where the button works.

The print preview bar can also get stuck if you try to refresh the page inside the print preview. The steps are: 1. Print preview 2. Hit F5 to refresh 3. Hit the close button Result: Print preview bar remains while the menu and address bars disappear for good in that window. In addition the page's print stylesheet did not get used. Expected result: The page to refresh inside the print preview making use of the print stylesheet, and for the close button to actually close. And this is also similiar to: https://bugzilla.mozilla.org/show_bug.cgi?id=300347

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

I am experiencing this defect in Firefox 1.5 RC3 --- always reproducible.

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

As noted in comment 6 happens in FF (and also on FF trunk) but not in the suite. Another way to create and test is drag and drop an html document into the print preview window. It should, but does not, trigger an error message "The document cannot change while Printing or in Print Preview" Apparently it's fixed in suite/Seamonkey. I can't find the fix. Changing to print preview component.

Confirming FF1.5 winXP.

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

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

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

(In reply to comment #12) > Still a problem in 1.0.4 > > I have firefox set: > Open links from other applications in: A new tab in the most recent window > Force Links to open in: A new tab > > 1. Open a page, goto print preview > 2. In another application (such as mirc) Open a link (in mirc, double click) > > Firefox brings the tab bar into view, opens the new tab as normal - only, there > is no address bar, menu bar etc - just the print preview stuff. All tabs > function as normal, links work etc. > > Close button has no effect > I have to close the window and restart FF to get my normal view back. (In reply to comment #12) > Still a problem in 1.0.4 > > I have firefox set: > Open links from other applications in: A new tab in the most recent window > Force Links to open in: A new tab > > 1. Open a page, goto print preview > 2. In another application (such as mirc) Open a link (in mirc, double click) > > Firefox brings the tab bar into view, opens the new tab as normal - only, there > is no address bar, menu bar etc - just the print preview stuff. All tabs > function as normal, links work etc. > > Close button has no effect > I have to close the window and restart FF to get my normal view back. Actually, you dont have to close the window and restart FF, you only need to close THAT NEW TAB and then the original window/tab can return you to FF by clicking the close button. Steve

I just tried the trick suggested by Steve Powell in the previous email to "Actually, you dont have to close the window and restart FF, you only need to close THAT NEW TAB and then the original window/tab can return you to FF by clicking the close button." It seems that this somehow has cured the problem and now I can go back and forth and successfully get out of the "print review" window. I wonder if someone can devise an effective fix based on my experience.

This screenshot shows the result of a page displaying a JavaScript alert() dialog while in print preview mode. Note that no new tab was created. In this instance, the page showing the alert dialog was loaded by a <meta http-equiv="refresh" .../> element. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9.

Clicking "OK" on the alert dialog, followed by close on the print preview toolbar results in a display of the tabs. Selecting the tab which was being previewed prior to losing focus, then clicking close on the print preview toolbar returns the browser to its normal state. In my case, the <meta http-equiv="refresh" .../> element was on the page being previewed and I could not re-open the print preview. Since I cannot re-open the print preview, I cannot close it to return the browser to normal. As I have demonstrated, opening a new tab is not needed. If an existing page in a different tab executes a JavaScript alert(), that tab will be focused. I think that Bug 133787 is the proper solution to this problem in the long term. I would be good if someone can confirm it in the latest builds/releases. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2 - Build ID: 2007021917 Exhibiting same behavior as noted. Print Previewing a page, switching to another application (ie: Outlook mail message) and clicking on hyperlink opens the page in a new tab (existing browser) with the Print Preview options "on top". "Close" button has no effect. HOWEVER, I can make the Print Preview options "go away" by selecting a different page orientation (ie: click on "Landscape"). Doing so allows me to click on the "Close" button, which in effect repaints the default menubar.

This is currently tagged as a Firefox bug, but with Seamonkey 1.1.5 I also get the "close button does nothing after pressing F5" behavior. It seems that the latest version of Firefox ignores F5 in print preview mode, so it has at least partially been addressed there.

Is this still the most recent bug report for this issue? I am still seeing it in Firefox 3 RC2 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0 If I am in Print Preview and I click on a link in IRC or IM or EMail it them opens a new tab but the browser stays in Print Preview mode. I can reproduce this every time.

I'm saddened to see that this bug still exists (I don't even use print preview these days so hadn't experienced it) since pre-1.0 when now 3.0 is close to release. However I have noticed that the close button only works in the tab that is set as a print preview. So If you accidentally close the tab thats in print preview, you get stuck there. I see a few possible solutions to this: 1) Close button should work in every tab 2) Closing a tab thats in print preview mode exits print preview mode 3) Make print preview open in a separate print preview only window (as per Bug #133787) 4) Switch to/from print preview depending on the current tab focus Ideally (imo) #3 would be what is done, but #1 or #2 will solve the problem of getting stuck in print preview mode.

It seems to me that this should be marked as dependent on Bug #133787 -- that's the best way to solve the issue, I think.

Tested with 3.6 Beta 3 and this issue still exists.

I still have this problem in the newest Firefox version 3.6.10. In the Bug 584272 somebody else described it again.

Bug still exists in 3.6.11 I also noted that the close button works if I switch back to the tab I originally opened Print Preview on.

Also experiencing locking print preview toolbar shenanigans, using 3.6.13 on Windows XP. To reproduce: 1. Have a tab with Google Calender open. 2. Open the print preview window for a tab in the same window and leave it open 3. Wait for Google Calender to pop-up a reminder alert 4. Look at your broken Browser that is displaying the content of the Google Calender page, but the print preview toolbar. 5. Attempt to escape by pressing "Close" or ESC, fail, and have to quit Firefox and restart. This happens to me a lot.

Bug is still present in 16.0.1

I don't think bug 629500 touches print preview in any way.

No, bug 629500 in and of itself probably won't help with this one. Also, nobody should be holding their breath for me to make forward progress on my printing projects -- I don't have a lot of time right now and even if I did I'd be spending a lot of it nagging other people to write code I can't write myself. That said, one of the things on my mental to-do list for printing is 'make print preview a tab mode rather than a window mode' which _should_ at least help with this bug.

no news about this?

Well, _I'm_ not planning to do any more printing work until someone helps me with bug 693230. Perhaps that someone could be you?