472389 - Print dialog disables DOM modifications (it's not modal)

Status: VERIFIED FIXED

(Core :: Print Preview, defect)

Description

[Tony Birnseth]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

Call window.print with a page of data.
Have Javascript at the bottom such as:
	if( window.print ) {
		resizeWin(800);
		window.print();
		restoreWinSize();
		setTimeout(\'window.history.back();\', 2000);
	}
In all versions of FF3, this is broken by the silly message about "page can't be changed".  In FF2 this behaved correctly.  I.e. after the page finished spooling, the window was resized back to original and it returned to the calling page.

This has been broken a long time and I'm forced to require my customers to use FF2.  Finally, the blank page between tables that had page-break-after:always was fixed, but this remains.

It is causing extreme inconvenience to my customers and does not allow them to utilize all the great things in FF3.


Reproducible: Always

Steps to Reproduce:
1. Create a page with the JS above at the bottom of the page.
2. You'll get a silly error message about not being able to change the page.
3. The JS is ignored and none of the events will fire.
Actual Results:  
Ugly screen stuck on the document page to be printed.

Expected Results:  
resizing of the window and return to the previous page.

Please just get rid of the "page cannot be modified" stuff and let the JS run...

Comment 1

[Tony Birnseth]

This has become critical to my application....
I'm having to tell users to load FF 2.0.15 to get correct behavior or (forbidden) telling them to use IE!!!!

This has gone on for a long time.  Can't you just remove the silly confirm box and not disable the javascript?

This is really important to me.

Comment 2

[Nochum Sossonko [:Natch]]

Can you attach a testcase displaying this particular problem. Also have you tested the latest development branch ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ ?

Comment 3

[Tony Birnseth]

Insert the javascript above at the end of any page you are printing.  window.print invokes the print preview.  But since there's javascript on the page and an event, the stupid dialog comes up and disables the events.  Hence the window is not resized and the user is not returned to the previous page.  They have to use the back button for every shipping label they print and resize the window.

As I said, this was all fine in FF2 and all versions of FF3 have this problem.  

What value is the confirming dialog?  There is no choice!!!

I have not tested from the latest branch.  I've seen no indication that anything has ever been done.  I check each new Update the comes and each one has the same problem.

For a test case, append the javascript above to any page and then load it.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Could you perhaps try latest nightly build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

That has changes to print preview and those changes will be also in 3.5
(but I haven't landed the patches to 3.5 branch yet).

Though, I'm not sure the changes bring the behavior you'd want :/

Comment 5

[Tony Birnseth]

I will verify when 3.5 comes out... again.
This has been haunting me for so long now that I've just about given up hope.
I don't understand why there's a "confirm" dialog at all.  It doesn't allow the user any option and seems to simply be worthless other than disabling valid javascript (or events) associated with a page.  If the user can't do anything, why ask for confirmation?  And why is the javascript (or events) disabled?  It doesn't affect printing.

None of this behavior makes any sense to me and I don't know what the intent was behind adding this "feature" to FF3 to begin with...

Unfortunately, I don't have the facility to try a nightly build without crushing the rest of my environment.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

It would be great if you could test the latest nightly build, 
or wait a day or two before I land the patches to 3.5 branch.
Testing a nightly is easy. Just download and unpack it and use a new profile for it. You may need to use -no-remote option with it too.

And it would also help a lot if you could post a *minimal* test case
using "add an attachment". The test case should explain what is the expected
behavior and what is the current behavior you see (and on which platform).

Comment 7

[Tony Birnseth]

Attachment: Tes case for window.print dialog disabling events.

Comment 8

[Tony Birnseth]

Added attachment that shows that following a window.print() call, that the dialog displayed disables any further javascript and/or events.

Comment 9

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7

The testcase works fine for me, I loaded my home page, then the testcase, hit cancel and the browser stepped back one page.

Comment 10

[Tony Birnseth]

Wait for the 2 seconds before clicking cancel.  The dialog will then appear and the remaining javascript won't be executed.  Seems like the window.print() function should be sequential.  I.e. it should complete before the setTimeout();  but it seems to be independent.  It appears that if the print is in process (I.e. the window.print() has yet to return) and the setTimeout(); fires that the dialog and subsquent zapping of the javascript occurs.

All I know is that this stupid dialog is new in FF3 and does not seem to add any value whatsoever other than breaking applications that used to work in FF2.

Comment 11

[Tony Birnseth]

Are you creating a new thread for the print and then have something that says:
if( I have a new event && the event I was waiting on hasn't completed)
   showASillyConfirmBox(that gives me no options but destroys my app behavior);

Comment 12

[Nochum Sossonko [:Natch]]

Yeah, that's a bit weird that the dialog doesn't stop the js, it seems to be modal, but seems to be an os dialog. Confirming, will see about latest-trunk.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Please test the latest nightly. It does change the behavior of timeouts
during print preview and printing.
Without getting any comments whether the new trunk behavior is ok, it is
impossible to implement something you'd like to get.

Comment 14

[Nochum Sossonko [:Natch]]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090318 Minefield/3.6a1pre
Hrm this is fixed on latest-trunk, not sure about 3.5 though.

Comment 15

[Tony Birnseth]

Natch, does this mean I don't have to verify on the latest trunk?  Really can't afford to mess up my environment with a potentially unstable build.

Does this mean it could be folded into whatever the next released update is?
I'm running 3.0.7, would be very pleasing to my customers if 3.0.8 were to address this issue.

Comment 16

[Nochum Sossonko [:Natch]]

As of now it seems with luck this will make it to 3.5.

As to running latest-trunk, see http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile to make a new profile, on which you could run the unstable build and mitigate any risk of running the "unstable" app.

Comment 17

[Tony Birnseth]

And target for 3.5 is...?  Not trying to be pushy, but now you have me excited that this might actually get fixed!

Comment 18

[Nochum Sossonko [:Natch]]

https://wiki.mozilla.org/Firefox3.5/Schedule .

Comment 19

[Nochum Sossonko [:Natch]]

Resolving as WORKSFORME, will add the fixed1.9.1 keyword once the patch lands. Smaug, please set this to fixed if bug 482976 is actually the one that fixed this.

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

Removing blocking flag - I approved bug 482976 for 191.

Comment 21

[Aakash Desai [:aakashd]]

verified FIXED on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090331 Minefield/3.6a1pre

and

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090401 Shiretoko/3.5b4pre