FragmentOrElement::SetXBLInsertionParent(nullptr) ends up slots if none exists, which is unnecessary. This is a problem if you call it after LastRelease(), which I'd like to do in bug 996151, but I think it is a reasonable improvement in any case.
> ends up slots if none exists This should be "ends up creating slots if none exists".
It looks like a similar change can be made for FragmentOrElement::SetXBLBinding().
Summary: Make FragmentOrElement::SetXBLInsertionParent(nullptr) lazier → Make SetXBLInsertionParent(nullptr) and SetXBLBinding(nullptr, ...) lazier
try run with asserts: https://tbpl.mozilla.org/?tree=Try&rev=9f4d86c48972 try run without asserts: https://tbpl.mozilla.org/?tree=Try&rev=00aafe8bcef0
Attachment #8413456 - Flags: review?(bugs)
Olli suggested this approach to figuring out why nodes weren't clearing their slots. I'm just attaching this for posterity.
Comment on attachment 8413456 [details] [diff] [review] Make SetXBLInsertionParent(nullptr) and SetXBLBinding(nullptr, ...) lazier. Do we want this on branches too? Looks rather bad to me.
Attachment #8413456 - Flags: review?(bugs) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/c25984096097 > Looks rather bad to me. Why is that? Do you think this will greatly increase the number of nodes with slots?
That and re-creating slots is odd too - but I guess the latter doesn't lead to any real problems after all.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
(In reply to Andrew McCreight [:mccr8] from comment #6) > Why is that? Do you think this will greatly increase the number of nodes > with slots? If you think this should go on branches, feel free to fill out the approval request. I think you understand the issue and potential problems better than me.
You need to log in before you can comment on or make changes to this bug.