Closed
Bug 268177
Opened 20 years ago
Closed 20 years ago
loadgroups don't handle loadgroups very well
Categories
(Core :: Networking, defect)
Core
Networking
Tracking
()
RESOLVED
FIXED
mozilla1.8alpha5
People
(Reporter: Biesinger, Assigned: Biesinger)
Details
Attachments
(1 file)
3.50 KB,
patch
|
darin.moz
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
- GetLoadGroup lacks an addref - the loadgroup never adds itself to mLoadGroup
Assignee | ||
Comment 1•20 years ago
|
||
Assignee | ||
Updated•20 years ago
|
Attachment #164970 -
Flags: review?(darin)
Assignee | ||
Updated•20 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8alpha5
Comment 2•20 years ago
|
||
Comment on attachment 164970 [details] [diff] [review] patch looks good, r=darin
Attachment #164970 -
Flags: review?(darin) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #164970 -
Flags: superreview?(bzbarsky)
Comment 3•20 years ago
|
||
Comment on attachment 164970 [details] [diff] [review] patch Hmmm... so without this patch cancelling a loadgroup for a document didn't cancel loadgroups for child documents? So an image loading in a frame would not get cancelled when the toplevel document got cancelled (because we'd cancel the subdocument's channel, but not its loadgroup)? If so, then watch things carefully for regressions after this lands... (and it's probably a good idea to check GetLoadGroup() callers in the tree to make sure none of them were relying on the buggy behavior you fixed). sr=bzbarsky.
Attachment #164970 -
Flags: superreview?(bzbarsky) → superreview+
Comment 4•20 years ago
|
||
bz: I don't think we ever added LoadGroups to other LoadGroups, so this is likely to affect any existing consumers. Or, I am mistaken? I made nsILoadGroup extend from nsIRequest relatively recently (w.r.t. uriloader/docloader design).
Assignee | ||
Comment 5•20 years ago
|
||
indeed - http://lxr.mozilla.org/seamonkey/search?string=-%3Esetloadgroup only shows channels that get put into loadgroups (and dummy requests). this is more of something for use in the future.
Comment 6•20 years ago
|
||
Perhaps I was unclear... Without this patch, a loadgroup (viewed as an nsIRequest) is not in any loadgroup. So the only way to cancel a loadgroup is to explicitly call Cancel() on it. At least as far as I can see. Am I missing something? With this patch, is a loadgroup placed in some parent loadgroup? I guess that only happens if someone called SetLoadGroup on the loadgroup. I guess comment 5 is saying that currently that does not happen?
Assignee | ||
Comment 7•20 years ago
|
||
> So the only way to cancel a loadgroup is to explicitly call Cancel() on it. that's correct >With this patch, is a loadgroup placed in some parent loadgroup? I guess that >only happens if someone called SetLoadGroup on the loadgroup. I guess comment 5 >is saying that currently that does not happen? right :)
Assignee | ||
Comment 8•20 years ago
|
||
Checking in netwerk/base/src/nsLoadGroup.cpp; /cvsroot/mozilla/netwerk/base/src/nsLoadGroup.cpp,v <-- nsLoadGroup.cpp new revision: 1.63; previous revision: 1.62 done
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 9•20 years ago
|
||
oops. this caused a bit of bustage (RemoveRequest takes 3 args). I fixed it by passing aStatus to removeRequest. that seems ok to me - it means the loadgroup will indicate the status of the last removed request; it's all we have (isn't it?)
You need to log in
before you can comment on or make changes to this bug.
Description
•