Closed Bug 137739 Opened 22 years ago Closed 22 years ago

[FIX]<body onload="print();"> triggers events in wrong order

Categories

(Core :: Printing: Output, defect, P2)

Product:
Core
Component:
Printing: Output
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: lucifer, Assigned: rods)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

patch
3.51 KB, patch
dcone
: review+
jst
: superreview+
Details | Diff | Splinter Review 
if a body tag has a print() as onLoad, a printer dialog is presented before the
page is displayed. i for one would like to see what i'm about to print :)
Reporter, what build are you using?  This worksforme on that page with build
2002-04-12-21 on Linux.
Confirmed on 2002041603 on Mac OS 9.2.2.  Changing platform and OS to All. 
Possible INVALID, but I think the page should display before the onload() is
processed, as in Netscape 4. (Prints fine, though.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
Hardware: PC → All
Keywords: 4xp
This is a dup
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: DUPME
Target Milestone: --- → Future
*** Bug 134384 has been marked as a duplicate of this bug. ***
Severity: minor → normal
Whiteboard: DUPME
Target Milestone: Future → mozilla1.0.1
Attached patch patch (obsolete) — — Splinter Review 
If the user or JS requests to print while the document is still loading the DV
adds a nsIDOMEventListener to watch for a "load", then schedules a PLEvent to
do the print.
Summary: <body onload="print();"> triggers events in wrong order → [FIX]<body onload="print();"> triggers events in wrong order
The document viewer already knows when the onload event will fire (actually, the
document viewer is the one fireing the onload handler, look in
DocumentViewer::LoadComplete()), so I don't see the need for adding the document
viewer as a DOM event listener at all. How about adding internal state to the
document viewer in stead and have it process the print commant from the code
that fires the onload handler if it can't be handled directly when print() is
called?
Attached patch patch — — Splinter Review 
Simplified patch, caches args when print is called during load, and then calls
print in the LoadComplete
Attachment #89396 - Attachment is obsolete: true
Comment on attachment 89496 [details] [diff] [review]
patch

@@ -1547,6 +1552,14 @@

   NS_RELEASE_THIS();

+  // Check to see if someone tried to print during the load
+  if (mPrintIsPending) {
+    mPrintDocIsFullyLoaded = PR_TRUE;
+    Print(mCachedPrintSettings, mCachedPrintWebProgressListner);
+    mCachedPrintSettings	    = nsnull;
+    mCachedPrintWebProgressListner = nsnull;
+  }

Seems like setting mPrintIsPending to PR_FALSE here would be a natural thing to
do, even if it doesn't really need to be set to PR_FALSE here...

sr=jst either way.
Attachment #89496 - Flags: superreview+
Comment on attachment 89496 [details] [diff] [review]
patch

r=dcone
Attachment #89496 - Flags: review+
fixed
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Since this fix, I am crashing when saving a compose message as draft in a local
folder because the object get released before we access to the member variable
mPrintIsPending. We need to move the line NS_RELEASE_THIS(); at the end of the
function just before the return!
I filed bug 156772 to track the regression.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: