Bug 66634 – Inserting <style> nodes in the DOM can be REALLY slow

• Status: NEW
• Component: WebKit2

[Marc Hoyois]

The command

document.body.appendChild(document.createElement("style"));

is way too slow on some pages.
Run it for example on http://www.google.com/ (seems instantaneous), and on http://www.w3.org/TR/DOM-Level-3-Core/core.html (takes about 1 second!).

[Alexey Proskuryakov]

I do see this with Safari 5.1 (didn't test ToT). I enter a javascript: url with the provided script while scrolling.

Surprisingly, this seems to only happen with WebKit2 windows, not with WebKit1 ones. And indeed, this only happens on some pages, and not any javascript: URL causes this causes this.

[Alexey Proskuryakov]

<rdar://problem/10009128>

[Alexey Proskuryakov]

Marc, does this cause any known user visible symptoms? Is this something that an extension might trigger?

[Marc Hoyois]

I was actually entering the command in the console so the problem is unrelated to javascript: URLs.

My ClickToFlash extension does use an inline stylesheet like this to manipulate the shadow DOM of its <video> elements, but I never noticed the problem with it (presumably because there is no delay on the pages where the extension creates video elements).

I noticed the problem with an HTML5-outliner bookmarklet that I did. I could work around the bug using the style attribute instead, but it's really impractical, especially since I need to reset lots of CSS properties.

Generally, any extension that needs lots of dynamic styles will want to use an inline stylesheet, so I think many extensions might be suffering from this delay.

Additional observation: actually adding lots of CSS styles using sheet.insertRule does not cause any visible delay once the <style> element is in the document.

Created attachment 187379 [details]
Sample HTML page with JavaScript demonstrating slow dynamic insertion of styles

Sample page that inserts 2000 styles.  It takes about 30 seconds on my Windows XP machine.  If I populate the "style" element before appending it to the "head" element, it takes about 19 milliseconds.

I have found that inserting style nodes can be extremely slow given the following two prerequisites:
1. The CSS text is \n separated
2. The head.appendChild(style) happens BEFORE style.innerText = '...css...'

In my example, I have 2000 styles.
If the above two conditions hold, it takes about 30 seconds to insert the styles.
If one of the conditions does not hold, it takes about 19 milliseconds.

I am attaching a sample that exhibits the problem.

[Marc Hoyois]

(In reply to comment #6)
> I have found that inserting style nodes can be extremely slow given the following two prerequisites:
> 1. The CSS text is \n separated
> 2. The head.appendChild(style) happens BEFORE style.innerText = '...css...'
> 
> In my example, I have 2000 styles.
> If the above two conditions hold, it takes about 30 seconds to insert the styles.
> If one of the conditions does not hold, it takes about 19 milliseconds.
> 
> I am attaching a sample that exhibits the problem.

You HAVE to do (2) or else the styles are not applied at all, in my experience...

[Simon Fraser (smfr)]

Sample shows all the time under:

      2328 WebCore::replaceChildrenWithFragment(WebCore::ContainerNode*, WTF::PassRefPtr<WebCore::DocumentFragment>, int&)  (in WebCore) + 277  [0x1022fe405]
        2328 WebCore::ContainerNode::appendChild(WTF::PassRefPtr<WebCore::Node>, int&, bool)  (in WebCore) + 278  [0x101981556]
          2328 WebCore::updateTreeAfterInsertion(WebCore::ContainerNode*, WebCore::Node*, bool)  (in WebCore) + 190  [0x101dc441e]
            2297 WebCore::StyleElement::process(WebCore::Element*)  (in WebCore) + 522  [0x1019c07ba]
            ! 1698 WebCore::StyleElement::createSheet(WebCore::Element*, WTF::OrdinalNumber, WTF::String const&)  (in WebCore) + 855  [0x10249ace7]
            ! : 1697 WebCore::StyleSheetContents::parseStringAtLine(WTF::String const&, int)  (in WebCore) + 66  [0x1024c7782]
            ! : | 1697 WebCore::CSSParser::parseSheet(WebCore::StyleSheetContents*, WTF::String const&, int, WTF::Vector<WTF::RefPtr<WebCore::CSSRuleSourceData>, 0ul>*)  (in WebCore) + 231  [0x101e0f457]
            ! : |   517 cssyyparse(WebCore::CSSParser*)  (in WebCore) + 15060  [0x101e05f64]
            ! : |   + 505 WebCore::CSSParser::parseValue(WebCore::CSSPropertyID, bool)  (in WebCore) + 16814  [0x101e16b2e]
            ! : |   + ! 278 WebCore::CSSParser::parseFillShorthand(WebCore::CSSPropertyID, WebCore::CSSPropertyID const*, int, bool)  (in WebCore) + 368  [0x101e20130]
            ! : |   + ! : 143 WebCore::CSSParser::parseFillProperty(WebCore::CSSPropertyID, WebCore::CSSPropertyID&, WebCore::CSSPropertyID&, WTF::RefPtr<WebCore::CSSValue>&, WTF::RefPtr<WebCore::CSSValue>&)  (in WebCore) + 572  [0x101e1962c]
            ! : |   + ! : | 120 WebCore::CSSParser::parseBackgroundColor()  (in WebCore) + 140  [0x101a3372c]
            ! : |   + ! : | + 82 WebCore::CSSParser::parseColorFromValue(WebCore::CSSParserValue*, unsigned int&)  (in WebCore) + 337  [0x1019484f1]
            ! : |   + ! : | + ! 65 WebCore::CSSParser::fastParseColor(unsigned int&, WTF::String const&, bool)  (in WebCore) + 2105  [0x101e11469]
            ! : |   + ! : | + ! : 37 WebCore::Color::setNamedColor(WTF::String const&)  (in WebCore) + 154  [0x1018d513a]
            ! : |   + ! : | + ! : | 20 WebCore::findColor(char const*, unsigned int)  (in WebCore) + 37  [0x1018d5195]
...

[Ahmad Saleem]

Created attachment 460813 [details]
Safari 15.5 is slower than other browsers

I am able to reproduce this bug in Safari 15.5 on macOS based on attached test case. As shown in the attached screenshot, Safari is slowest among other browsers.

I think improving performance or matching to competitors would be ideal here. Thanks!