WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
81378
Forbid event dispatch during teardown of a Document/DOM tree
https://bugs.webkit.org/show_bug.cgi?id=81378
Summary
Forbid event dispatch during teardown of a Document/DOM tree
Adam Klein
Reported
2012-03-16 11:46:49 PDT
Forbid event dispatch during teardown of a Document/DOM tree
Attachments
Patch
(2.19 KB, patch)
2012-03-16 11:47 PDT
,
Adam Klein
no flags
Details
Formatted Diff
Diff
Patch with motivation
(2.87 KB, patch)
2012-03-16 13:31 PDT
,
Adam Klein
no flags
Details
Formatted Diff
Diff
Moved from ~ContainerNode to removeAllChildren
(2.85 KB, patch)
2012-03-26 17:47 PDT
,
Adam Klein
no flags
Details
Formatted Diff
Diff
Proposed renaming of removeAllChildren
(7.74 KB, patch)
2012-03-26 18:17 PDT
,
Adam Klein
no flags
Details
Formatted Diff
Diff
Show Obsolete
(3)
View All
Add attachment
proposed patch, testcase, etc.
Adam Klein
Comment 1
2012-03-16 11:47:23 PDT
Created
attachment 132332
[details]
Patch
Alexey Proskuryakov
Comment 2
2012-03-16 12:31:25 PDT
Comment on
attachment 132332
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=132332&action=review
> Source/WebCore/ChangeLog:8 > + No new tests, no change in behavior.
Please explain why this change is needed then.
Adam Klein
Comment 3
2012-03-16 13:31:53 PDT
Created
attachment 132360
[details]
Patch with motivation
Adam Klein
Comment 4
2012-03-20 14:20:43 PDT
Adding some of my favorite reviewers...
Ojan Vafai
Comment 5
2012-03-20 14:54:07 PDT
Comment on
attachment 132360
[details]
Patch with motivation This looks fine to me, but should we instead put the forbid/allow directly in removeAllChildren? That documents the no event dispatch where the code that assumes it.
Adam Klein
Comment 6
2012-03-20 14:55:02 PDT
(In reply to
comment #5
)
> (From update of
attachment 132360
[details]
) > This looks fine to me, but should we instead put the forbid/allow directly in removeAllChildren? That documents the no event dispatch where the code that assumes it.
Well, there's more happening in Document::removedLastRef than just the removeAllChildren...maybe it should go there instead of ~ContainerNode, though?
Adam Klein
Comment 7
2012-03-26 17:47:51 PDT
Created
attachment 133944
[details]
Moved from ~ContainerNode to removeAllChildren
Ryosuke Niwa
Comment 8
2012-03-26 17:51:05 PDT
Comment on
attachment 133944
[details]
Moved from ~ContainerNode to removeAllChildren View in context:
https://bugs.webkit.org/attachment.cgi?id=133944&action=review
> Source/WebCore/dom/ContainerNode.cpp:84 > void ContainerNode::removeAllChildren()
Maybe we should rename this function to signify the fact it shouldn't dispatch any events?
Adam Klein
Comment 9
2012-03-26 17:52:13 PDT
(In reply to
comment #8
)
> (From update of
attachment 133944
[details]
) > View in context:
https://bugs.webkit.org/attachment.cgi?id=133944&action=review
> > > Source/WebCore/dom/ContainerNode.cpp:84 > > void ContainerNode::removeAllChildren() > > Maybe we should rename this function to signify the fact it shouldn't dispatch any events?
Any suggestions? I chatted with Ojan about this for awhile and didn't come up with any names I liked better. tearDownSubTree?
Adam Klein
Comment 10
2012-03-26 18:17:53 PDT
Created
attachment 133954
[details]
Proposed renaming of removeAllChildren
Ryosuke Niwa
Comment 11
2012-03-26 18:37:49 PDT
Comment on
attachment 133954
[details]
Proposed renaming of removeAllChildren View in context:
https://bugs.webkit.org/attachment.cgi?id=133954&action=review
> Source/WebCore/dom/ContainerNode.cpp:87 > removeAllChildrenInContainer<Node, ContainerNode>(this);
Should we also rename removeAllChildrenInContainer?
> Source/WebCore/dom/ContainerNode.h:67 > + // Destroys the entire subtree without dispatching any events.
We wouldn't need this comment if we added WithoutEvents to the function name.
> Source/WebCore/dom/ContainerNode.h:68 > + // Meant to be called only during teardown (e.g., Document::~Document) or by the parser.
This comment seems to repeat what the code (~Document and parser) says. Also, the word "destroy" makes it pretty clear that we shouldn't be calling this function without a care.
Early Warning System Bot
Comment 12
2012-03-26 19:08:19 PDT
Comment on
attachment 133954
[details]
Proposed renaming of removeAllChildren
Attachment 133954
[details]
did not pass qt-wk2-ews (qt): Output:
http://queues.webkit.org/results/12143253
Early Warning System Bot
Comment 13
2012-03-26 19:18:03 PDT
Comment on
attachment 133954
[details]
Proposed renaming of removeAllChildren
Attachment 133954
[details]
did not pass qt-ews (qt): Output:
http://queues.webkit.org/results/12142251
Eric Seidel (no email)
Comment 14
2012-04-19 15:59:53 PDT
Comment on
attachment 133954
[details]
Proposed renaming of removeAllChildren I think this is a very good idea. But requires more careful thought/review than I have time for at the moment.
Adam Klein
Comment 15
2012-04-19 16:48:58 PDT
Comment on
attachment 133954
[details]
Proposed renaming of removeAllChildren This is still on my radar (I've got a local git branch of it), but needs some fixing before it goes back up for review. I'll take it out of the queue for clarity's sake.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug