Changeset 140452 in webkit


Ignore:
Timestamp:
Jan 22, 2013, 12:57:32 PM (13 years ago)
Author:
esprehn@chromium.org
Message:

Assertion parent->inDocument() failed in WebCore::PseudoElement::PseudoElement
https://bugs.webkit.org/show_bug.cgi?id=106224

Reviewed by Ojan Vafai.

Appending a node that contains a <style> and also elements that should have
generated content can cause us to create PseudoElements in nodes that are not
yet inDocument because we may recalcStyle in HTMLStyleElement::insertedInto
triggering a reattach() which could then traverse into the siblings of the
<style> attaching them even though they are not yet inDocument.

This means that we should not assert about the parent of a PseudoElement
being inDocument as this is not always the case.

Instead forward Node::insertedInto and removedFrom notifications to
PseudoElements so they will correctly get their inDocument bit set. Nothing
in the code appears to depend on them being inDocument we just make sure to
set it so they're consistent with the rest of the document.

No new tests, there's no way to test that PseudoElements are really inDocument.

  • dom/Element.cpp:

(WebCore::Element::insertedInto):
(WebCore::Element::removedFrom):

  • dom/PseudoElement.cpp:

(WebCore::PseudoElement::PseudoElement):

Location:
trunk/Source/WebCore
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • trunk/Source/WebCore/ChangeLog

    r140448 r140452  
     12013-01-22  Elliott Sprehn  <esprehn@chromium.org>
     2
     3        Assertion parent->inDocument() failed in WebCore::PseudoElement::PseudoElement
     4        https://bugs.webkit.org/show_bug.cgi?id=106224
     5
     6        Reviewed by Ojan Vafai.
     7
     8        Appending a node that contains a <style> and also elements that should have
     9        generated content can cause us to create PseudoElements in nodes that are not
     10        yet inDocument because we may recalcStyle in HTMLStyleElement::insertedInto
     11        triggering a reattach() which could then traverse into the siblings of the
     12        <style> attaching them even though they are not yet inDocument.
     13
     14        This means that we should not assert about the parent of a PseudoElement
     15        being inDocument as this is not always the case.
     16
     17        Instead forward Node::insertedInto and removedFrom notifications to
     18        PseudoElements so they will correctly get their inDocument bit set. Nothing
     19        in the code appears to depend on them being inDocument we just make sure to
     20        set it so they're consistent with the rest of the document.
     21
     22        No new tests, there's no way to test that PseudoElements are really inDocument.
     23
     24        * dom/Element.cpp:
     25        (WebCore::Element::insertedInto):
     26        (WebCore::Element::removedFrom):
     27        * dom/PseudoElement.cpp:
     28        (WebCore::PseudoElement::PseudoElement):
     29
    1302013-01-22  Alexis Menard  <alexis@webkit.org>
    231
  • trunk/Source/WebCore/dom/Element.cpp

    r140411 r140452  
    11391139#endif
    11401140
     1141    if (Element* before = pseudoElement(BEFORE))
     1142        before->insertedInto(insertionPoint);
     1143
     1144    if (Element* after = pseudoElement(AFTER))
     1145        after->insertedInto(insertionPoint);
     1146
    11411147    if (!insertionPoint->isInTreeScope())
    11421148        return InsertionDone;
     
    11701176    bool wasInDocument = insertionPoint->document();
    11711177#endif
     1178
     1179    if (Element* before = pseudoElement(BEFORE))
     1180        before->removedFrom(insertionPoint);
     1181
     1182    if (Element* after = pseudoElement(AFTER))
     1183        after->removedFrom(insertionPoint);
    11721184
    11731185#if ENABLE(DIALOG_ELEMENT)
  • trunk/Source/WebCore/dom/PseudoElement.cpp

    r137715 r140452  
    4545{
    4646    ASSERT(pseudoId != NOPSEUDO);
    47     ASSERT(parent->inDocument());
    4847    setParentOrHostNode(parent);
    4948    setHasCustomCallbacks();
Note: See TracChangeset for help on using the changeset viewer.