[Webkit-unassigned] [Bug 26279] REGRESSION: typing in gmail pegs CPU

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 15 18:17:51 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=26279





------- Comment #14 from ojan at chromium.org  2009-06-15 18:17 PDT -------
I have a reproduction. I'm pretty sure this is the gmail hang in that it's
clearly a performance bug and it gets fixed by all the same things people have
noticed (clicking elsewhere, hitting enter, etc).

Go to the following page:
http://www.plexode.com/cgi-bin/eval3.py#ht=%3Cdiv%20contentEditable%20style%3D%22border%3A%201px%20solid%22%3E%0A%20%20%3Cbr%3E%3Cdiv%3Ed%3C%2Fdiv%3E%0A%3C%2Fdiv%3E%0A&ohh=1&ohj=1&jt=&ojh=1&ojj=1&ms=100&oth=0&otj=0&cex=1

1. Set a breakpoint at line 220 of InsertTextCommand.cpp
applyStyle(typingStyle). This should only be hit if there is a typingStyle.
2. Click in the first line of the contentEditable div (above the 'd').
3. Do a forward-delete
4. Type any character

At step 4, the breakpoint gets hit and shouldn't. A typingStyle should not have
been set. More importantly, it's not getting cleared. To see that type any
character again and see that we keep hitting the breakpoint.

I'm pretty sure this bug was introduced with
http://trac.webkit.org/changeset/43243. The problem is in
CSSComputedStyleDeclaration::copyInheritableProperties we do the following
transformation:
    if (int keywordSize =
m_node->computedStyle()->fontDescription().keywordSize())
        style->setProperty(CSSPropertyFontSize,
cssIdentifierForFontSizeKeyword(keywordSize));

But then in DeleteSelectionCommand::calculateTypingStyleAfterDelete, we call:
    RefPtr<CSSComputedStyleDeclaration> endingStyle =
computedStyle(m_endingPosition.node());
    endingStyle->diff(m_typingStyle.get());
    if (!m_typingStyle->length())
        m_typingStyle = 0;

m_typingStyle->length() should be 0, but in practice, the length is 1. There is
a font-size property that didn't get removed in
endingStyle->diff(m_typingStyle.get()).

At first glance, it looks like the fix should be in CSSStyleDeclaration::diff.
When we compare CSS values, we need to treat font-size specially here as well,
doing the same transformation that we do in copyInheritableProperties.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list