Closed
Bug 820889
Opened 13 years ago
Closed 13 years ago
convert PendingBinding to use mozilla::LinkedList
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: froydnj, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
7.34 KB,
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
No description provided.
![]() |
Reporter | |
Comment 1•13 years ago
|
||
The only tricky bit here is that, unlike PRCList, the list doesn't double
as an element of the list. So we have to be a little more circumspect in
adding members.
Attachment #691384 -
Flags: review?(dholbert)
Comment 2•13 years ago
|
||
Comment on attachment 691384 [details] [diff] [review]
convert PendingBinding to use mozilla::LinkedList
This generally looks good -- there was just one potentially-problematic thing that I noticed, in the final chunk:
>+ if (!mPendingBindings.isEmpty()) {
> nsBindingManager* bindingManager = mPresShell->GetDocument()->BindingManager();
> do {
>- PendingBinding* pendingBinding =
>- static_cast<PendingBinding*>(PR_NEXT_LINK(&mPendingBindings));
>- PR_REMOVE_LINK(pendingBinding);
>+ PendingBinding* pendingBinding = mPendingBindings.popFirst();
> bindingManager->AddToAttachedQueue(pendingBinding->mBinding);
>- delete pendingBinding;
>- } while (!PR_CLIST_IS_EMPTY(&mPendingBindings));
>+ } while (!mPendingBindings.isEmpty());
>+ mCurrentPendingBindingInsertionPoint = nullptr;
Is it really OK to remove "delete pendingBinding;" there? What takes care of freeing that memory now?
(If we need to add something to free it, it'd probably be best to use an nsAutoPtr -- i.e. replace "PendingBinding* pendingBinding" with "nsAutoPtr<PendingBinding> pendingBinding" there.)
![]() |
Reporter | |
Comment 3•13 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #2)
> Comment on attachment 691384 [details] [diff] [review]
> convert PendingBinding to use mozilla::LinkedList
>
> This generally looks good -- there was just one potentially-problematic
> thing that I noticed, in the final chunk:
>
> >+ if (!mPendingBindings.isEmpty()) {
> > nsBindingManager* bindingManager = mPresShell->GetDocument()->BindingManager();
> > do {
> >- PendingBinding* pendingBinding =
> >- static_cast<PendingBinding*>(PR_NEXT_LINK(&mPendingBindings));
> >- PR_REMOVE_LINK(pendingBinding);
> >+ PendingBinding* pendingBinding = mPendingBindings.popFirst();
> > bindingManager->AddToAttachedQueue(pendingBinding->mBinding);
> >- delete pendingBinding;
> >- } while (!PR_CLIST_IS_EMPTY(&mPendingBindings));
> >+ } while (!mPendingBindings.isEmpty());
> >+ mCurrentPendingBindingInsertionPoint = nullptr;
>
> Is it really OK to remove "delete pendingBinding;" there? What takes care
> of freeing that memory now?
Doh! Yeah, that's no good. Will nsAutoPtr that.
Comment 4•13 years ago
|
||
Comment on attachment 691384 [details] [diff] [review]
convert PendingBinding to use mozilla::LinkedList
Cool -- r=me with that fixed.
Attachment #691384 -
Flags: review?(dholbert) → review+
Comment 5•13 years ago
|
||
Looks like this code was all added by bz, in bug 526178, back in 2009. Adding dependency & CC'ing bz in case he has anything to add.
Depends on: 526178
Version: unspecified → Trunk
![]() |
||
Comment 6•13 years ago
|
||
Other than the leak issue, I suspect there's no point nulling out mCurrentPendingBindingInsertionPoint in the destructor there. Not that it hurts to do it, I guess.
The rest seems fine.
![]() |
Reporter | |
Comment 7•13 years ago
|
||
Comment 8•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
You need to log in
before you can comment on or make changes to this bug.
Description
•