Closed Bug 293818 Opened 20 years ago Closed 20 years ago

[FIXr]Need document API for deferring onload

Categories

(Core :: DOM: Core & HTML, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla1.8beta2

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file, 2 obsolete files)

We've discussed this a few times, and I've run into really needing it for some work I'm doing, so I went ahead and put this together...
Attached patch Proposed patch (obsolete) — Splinter Review
This is a really basic impl; we may want to make BlockOnload() be a no-op if onload has already fired, but that's something I'd be leery of trying to do in 1.8....
Attachment #183324 - Flags: superreview?(jst)
Attachment #183324 - Flags: review?(darin)
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Summary: Need document API for deferring onload → [FIX]Need document API for deferring onload
Target Milestone: --- → mozilla1.8beta2
Blocks: 293825
Why does nsOnloadBlocker need a mLoadGroup member variable? Who calls SetLoadGroup/GetLoadGroup on it?
Hmm... Apparently no one. I thought adding to the loadgroup did... Should I be setting it before I call AddRequest on the loadgroup? We seem to do that for our current dummy layout requests.
I don't see any reason for this request to have a loadgroup of its own. Normally, one sets a loadgroup on a request, so that that request will automatically add and remove itself from the loadgroup when it starts and finishes. In this case, you are manually adding/removing the request to/from the loadgroup, so there is no need to tell the request about the loadgroup ;-)
Ah, I see. Sounds good. Consider that member and the relevant code removed. ;)
Comment on attachment 183324 [details] [diff] [review] Proposed patch sr=jst
Attachment #183324 - Flags: superreview?(jst) → superreview+
Comment on attachment 183324 [details] [diff] [review] Proposed patch r=darin w/ the loadgroup cruft that we discussed removed.
Attachment #183324 - Flags: review?(darin) → review+
Attached patch Patch updated to comments (obsolete) — Splinter Review
Requesting 1.8b2 approval... This is a pretty safe patch that shouldn't change any existing behavior but should make some other changes I'm still aiming for for 1.8 much simpler.
Attachment #183324 - Attachment is obsolete: true
Attachment #183424 - Flags: approval1.8b2?
Summary: [FIX]Need document API for deferring onload → [FIXr]Need document API for deferring onload
Comment on attachment 183424 [details] [diff] [review] Patch updated to comments a=asa
Attachment #183424 - Flags: approval1.8b2? → approval1.8b2+
Attached patch Merged to tipSplinter Review
Attachment #183424 - Attachment is obsolete: true
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Does this allow replacing the DummyLayoutRequest? If so, could you file a bug on that?
Blocks: 294114
Blocks: 294115
That was one of the goals, yes. For 1.9, I'd like to try. Bug 294114 filed for the layout request, and bug 294115 filed for the parser request.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: