RESOLVED FIXED 9561
REGRESSION: Content property on :before of button causes hang on click or hover
https://bugs.webkit.org/show_bug.cgi?id=9561
Summary REGRESSION: Content property on :before of button causes hang on click or hover
Troy Brandt
Reported 2006-06-23 21:41:48 PDT
The content property in this example causes WebKit to hang. The example uses this: #submit:before { content: "\2714"; } #clear:before { content: "\2718"; text-shadow: black 0.2em 0.1em 0.1em } And on load the app hangs. Removing the content property allows the page to load normally. This works as expected in Safari 2.0.3 and Camino.
Attachments
Example document. (989 bytes, text/html)
2006-06-23 21:42 PDT, Troy Brandt
no flags
Reduction of test case, non-aqua button (358 bytes, text/html)
2006-06-24 05:29 PDT, jonathanjohnsson
no flags
Reduction of test case, aqua button (216 bytes, text/html)
2006-06-24 05:31 PDT, jonathanjohnsson
no flags
Possible fix, no test or change log yet (6.76 KB, patch)
2006-06-25 09:45 PDT, mitz
hyatt: review-
Updated patch, including change log and test (74.62 KB, patch)
2006-06-27 12:05 PDT, mitz
darin: review+
Troy Brandt
Comment 1 2006-06-23 21:42:51 PDT
Created attachment 8993 [details] Example document.
jonathanjohnsson
Comment 2 2006-06-24 05:29:19 PDT
Created attachment 8998 [details] Reduction of test case, non-aqua button Hovering the button in this test case will hang Safari.
jonathanjohnsson
Comment 3 2006-06-24 05:31:18 PDT
Created attachment 8999 [details] Reduction of test case, aqua button When reducing the test case even further, the button reverts to an aqua look, and doesn't seem to react to hovering at all, so WebKit doesn't hang. Clicking the button hangs WebKit, though.
jonathanjohnsson
Comment 4 2006-06-24 05:35:30 PDT
I just reduced the original example a bit, to make it more to the point. It seems that it is the style change on hovering or clicking that triggers the hang.
mitz
Comment 5 2006-06-24 14:29:33 PDT
(In reply to comment #3) > Created an attachment (id=8999) [edit] > Reduction of test case, aqua button  A debug build fails the assertion KHTMLAssert(beforeChild->parent()->isAnonymousBlock()) in RenderBlock::addChildToFlow() when I click the button.
mitz
Comment 6 2006-06-25 09:45:45 PDT
Created attachment 9019 [details] Possible fix, no test or change log yet This patch is somewhat cumbersome. Another approach I considered was to patch RenderButton::setStyle() and RenderButton::addChild() to copy the pseudostyles to the inner div, but I had a feeling it would end up being at least as complicated as this patch's approach.
Darin Adler
Comment 7 2006-06-25 10:16:15 PDT
Comment on attachment 9019 [details] Possible fix, no test or change log yet I'm not a big fan of functions that have those "do" prefixes. It's always hard to know how they differ from the version without the "do" prefix. It's just "stage 2". We should seek out a better name for the non-virtual core implementation of updatePseudoChild. In what cases will it ever be good for RenderButton to call doUpdatePseudoChild on itself rather than on m_inner? Architecturally, the worst thing here is the knowledge in RenderContainer::updatePseudoChild that the parent is special when it's a RenderButton. That needs a comment at least. And we should see what we can do to avoid this new slightly-fragile linkage between the classes. Even having a virtual function that was named something cumbersome like "updatesPseudoChildForChildren" might be better.
mitz
Comment 8 2006-06-25 10:31:22 PDT
(In reply to comment #7) > We should seek out a better name for the non-virtual core > implementation of updatePseudoChild. I'll give it more thought. > In what cases will it ever be good for RenderButton to call doUpdatePseudoChild > on itself rather than on m_inner? <style>     button:hover:before { content: 'foo' } </style> <button></button> The first time you hover, m_inner is 0. > Architecturally, the worst thing here is the knowledge in > RenderContainer::updatePseudoChild that the parent is special when it's a > RenderButton. That needs a comment at least. And we should see what we can do > to avoid this new slightly-fragile linkage between the classes. Even having a > virtual function that was named something cumbersome like > "updatesPseudoChildForChildren" might be better. I would just like to mention that there is already one virtual function that uniquely identifies buttons, and it's called allowsReusingAnonymousChild() :-).
Dave Hyatt
Comment 9 2006-06-26 02:49:55 PDT
Comment on attachment 9019 [details] Possible fix, no test or change log yet Gist of the fix looks right. I would actually recommend reusing the virtual "allowsReusingAnonymousChild" for this code. It has the advantage of being slightly more generic (since I expect the select popup control may run into this issue too) and entirely appropriate. Then you don't need the new isButton method at all.
Dave Hyatt
Comment 10 2006-06-26 02:51:57 PDT
Ah, I should have read the comments (just jumped right to the patch from the review queue). :)
mitz
Comment 11 2006-06-27 12:05:19 PDT
Created attachment 9065 [details] Updated patch, including change log and test I unified !allowsReusingAnonymousChild() with isButton() and renamed it createsAnonymousWrapper(). Also renamed doUpdatePseudoChild() to updatePseudoChildForObject() but I'll welcome other suggestions.
Darin Adler
Comment 12 2006-06-28 08:18:30 PDT
Comment on attachment 9065 [details] Updated patch, including change log and test Looks good. r=me Perhaps we can think of an even better name for the updatePseudoChildForObject function some day, but this seems good.
Darin Adler
Comment 13 2006-06-28 08:36:45 PDT
Committed revision 15079.
Note You need to log in before you can comment on or make changes to this bug.