Closed Bug 177491 Opened 22 years ago Closed 3 years ago

Open new page while in Print Preview, new link gets loaded in Print Preview window

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: tuttle_james, Unassigned)

References

Details

Attachments

(3 files)

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
Assignee: asa → rods
Component: Browser-General → Print Preview
QA Contact: asa → sujay
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.
Status: UNCONFIRMED → NEW
Component: Print Preview → General
Ever confirmed: true
Product: Browser → Firefox
Summary: If Windows opens a new link while Mozilla is in Print Preview, new link gets loaded in Print Preview window (and gets stuck there) → If Windows opens a new link while Firefox is in Print Preview, new link gets loaded in Print Preview window (and gets stuck there)
Version: Trunk → unspecified
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.
Assignee: rods → firefox
QA Contact: sujay → firefox.general
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.
OS: Windows 2000 → All
Hardware: PC → All
*** 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.
Assignee: firefox → printing
Component: General → Print Preview
Product: Firefox → Core
QA Contact: general
Summary: If Windows opens a new link while Firefox is in Print Preview, new link gets loaded in Print Preview window (and gets stuck there) → Open new page while in Print Preview, new link gets loaded in Print Preview window
Version: unspecified → Trunk
Attached image Screen shot
*** 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.
Assignee: printing → nobody
Component: Print Preview → Tabbed Browser
Product: Core → Firefox
QA Contact: tabbed.browser
Flags: in-litmus?
Flags: blocking-firefox3?
Severity: normal → major
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [wanted-firefox3]
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.
Flags: wanted-firefox3+
Whiteboard: [wanted-firefox3]
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.
Depends on: 133787
Bug is still present in 16.0.1
I don't think bug 629500 touches print preview in any way.
No longer depends on: 629500
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?
Flags: in-litmus?

Marking this as Resolved > Worksforme since the issue no longer is reproducible on the latest versions of Firefox Nightly 95.0a1 (2021-10-13), beta 94.0b5 or release 93.0 on Windows 10.
If anyone can still reproduce the issue either re-open it or file a new one.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: