Open Bug 165694 Opened 23 years ago Updated 3 years ago

Changed window.print() Behaviour in Mozilla 1.1

Categories

(Core :: Printing: Output, enhancement, P3)

Product:
Core
Component:
Printing: Output
Platform:
x86
Windows 95
Type:
enhancement

Tracking

()

Milestone:
Future

People

(Reporter: ideservefreesoftware, Unassigned)

Details

With Mozilla 1.0 the following code: <html> <body> <script type="text/javascript"> <!-- alert('before printdialog'); window.print(); alert('after printdialog'); //--> </script> </body> </html> shows the Printing-dialog after the first and before the second Alert-dialog (as assumed). With Mozilla 1.1 both Alert-dialogs appear one after another and the Printing-dialog is opened only after those. Is this behaviour intended? I have some trouble with JavaScript which prints a page and changes the page after that. Mozilla 1.1 prints the new page instead of the former one due to the new behaviour.
related? bug 165445
I suspect this change was intentional, since our new behavior matches IE's.
#2: Is there a JavaScript-specification Mozilla could follow or does Mozilla just have to copy IE's bevaviour? The former behaviour was much more flexible: _If_ you wanted to print at the end of the script, you could put the print() command at the end. If you want to print at another position you could also do that.
I am not sure what the other browsers are "suppose" to do or what they do do. But we cannot print until the entire document is loaded. So our behavior going forward will always be: Not matter where the "print" request is issued in the page, the request will get "queued" until the entire document is loaded and then the "print" will happen as if you if selected File->Print.
jst, does this sound reasonable? Because I am not sure we can change this behavior.
Sounds reasonable to me, but if IE lets you do partial prints by putting window.print() calls in inline script and if people really do rely on that then maybe we should reconsider how we do this in Mozilla. For now, the current implementation seems fine to me.
I'm not sure about IE's window.print()-behaviour, for my colleague is taking care of the MS-platform. I even thought that IE couldn't do a window.print() at all. I just know that he has to do a very dirty looking but in the IE-world quite common print command to get Mozilla's former window.print()-behaviour: try { var webBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"> </OBJECT>'; document.body.insertAdjacentHTML('beforeEnd', webBrowser); WebBrowser1.ExecWB(6,2); //Use a 1 vs. a 2 for a prompting dialog box WebBrowser1.outerHTML = ""; } catch(e) { window.location.reload(); // Or the button will never work again! // This fixes a bug in IE5.x } I'm not demanding this feature. I just want to follow the standards. In case there is no standard, I suggest to support both variants: Printing after the page is completely processed, and immediate-printing to be able to go on with a automatic submit afterward like many pages do. (Consider an application using web-technology without Previous/Next-Buttons: You can't go back after you have loaded a link- and button-free print version.)
Currently, if a print request happens while the document is loading we queue the request. I am not sure we can support printing before the document is complete, that would take more investigation. I you want to be able to print from an "onload" handler or print with script in the document and then either load a new document OR have the document go "back" this is covered under Bug 165445
I agree that the onload method is fine. Allowing to print anywhere in the document is sometimes more comfortable, but if this results in an less elegant software design, or if it is even not considered at all, there's no need to spend more time on it. As my main problem is covered by Bug 165445, I suggest to resolve this bug.
Because this does capture a desired feature, I am changing it to an "enhancement" request.
Severity: normal → enhancement
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → Future
I have a question: when calling window.print() it seems that it doesn't remember the page setup and prints Url, margins etc. Is this a bug or a feature from W3C? Should I post this as a bug?
I don't know if that's as designed or not, but it's not something the W3C says anything about, they don't define anything related to the window object in any of their specs. Feel free to file a new bug on that.
Assignee: rods → nobody
Status: ASSIGNED → NEW
QA Contact: sujay → printing
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.