Closed
Bug 568188
Opened 15 years ago
Closed 14 years ago
Make id-table hold weak references
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: sicking, Assigned: sicking)
References
(Blocks 1 open bug)
Details
(Keywords: perf)
Attachments
(1 file)
(deleted),
patch
|
smaug
:
review+
bzbarsky
:
feedback+
jst
:
approval2.0+
|
Details | Diff | Splinter Review |
Right now the id-table holds strong references since we don't guarantee that elements are always removed from the id-table in all edge cases. Once bug 564863 is fixed, we can make the remaining effort to make it so that the id table is always correct and up to date.
There are two big complications:
* IDs for XML elements which can dynamically change which attribute is the ID attribute.
* Mutation events.
Patch coming up to fix
Attachment #447495 -
Flags: review?(Olli.Pettay)
Attachment #447495 -
Flags: feedback?(bzbarsky)
Assignee | ||
Comment 1•15 years ago
|
||
FWIW, I'm not 100% sure we want to do this given how much complexity there is. Though if we got rid of mutation events that would take care of almost all of the complexity.
Comment 2•15 years ago
|
||
Does the addref/release show up badly in profiles?
I guess it does.
Updated•15 years ago
|
Attachment #447495 -
Flags: review?(Olli.Pettay) → review+
Comment 3•15 years ago
|
||
Comment on attachment 447495 [details] [diff] [review]
Patch to fix
> nsIdentifierMapEntry::RemoveIdElement(Element* aElement)
> {
>+ NS_PRECONDITION(aElement, "Missing element");
>+
> // This should only be called while the document is in an update.
> // Assertions near the call to this method guarantee this.
>
>+ // This could fire in OOM situations
>+ // Only assert this in HTML documents for now as XUL does all sorts of weird
>+ // crap.
>+ NS_ASSERTION(!aElement->GetOwnerDoc() ||
>+ !aElement->GetOwnerDoc()->IsHTML() ||
>+ mIdContentList.IndexOf(aElement) >= 0,
>+ "Removing id entry that doesn't exist");
Please file followups for the crap.
And what all badness does XUL do?
But this isn't too bad, especially if you could have some
inline method like MaybeUpdatedIDAttribute() { nsMutationGuard::DidMutate(); }
That would be, IMO, easier to understand than just non-commented nsMutationGuard::DidMutate()
call.
Assignee | ||
Comment 4•15 years ago
|
||
> But this isn't too bad, especially if you could have some
> inline method like MaybeUpdatedIDAttribute() { nsMutationGuard::DidMutate(); }
> That would be, IMO, easier to understand than just non-commented
> nsMutationGuard::DidMutate()
> call.
Not sure where you want me to make this change? Note that we've previously not made a distinction of different types of mutations. So we might later end up with code that cares about other attribute changes, not just id-related ones.
It could make sense to add a comment to SetPrefix describing why this mutation is significant?
Comment 5•15 years ago
|
||
Well, add comment to all the places where you add nsMutationGuard::DidMutate().
That would be as helpful as inline method.
Assignee | ||
Comment 6•15 years ago
|
||
Filed bug 568282 on the XUL crappyness.
Comment 7•14 years ago
|
||
Comment on attachment 447495 [details] [diff] [review]
Patch to fix
Jonas, do you still want feedback here? Patch looks generally ok to me at first glance...
Attachment #447495 -
Flags: feedback?(bzbarsky) → feedback+
Assignee | ||
Updated•14 years ago
|
Attachment #447495 -
Flags: approval2.0?
Updated•14 years ago
|
Attachment #447495 -
Flags: approval2.0? → approval2.0+
Comment 8•14 years ago
|
||
Should this be pushed?
Assignee | ||
Comment 9•14 years ago
|
||
This was pushed a while ago. Forgot marking this fixed
http://hg.mozilla.org/mozilla-central/rev/e1b3964e946c
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•