[Webkit-unassigned] [Bug 11031] Another crazy counters bug
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Nov 17 22:08:49 PST 2009
https://bugs.webkit.org/show_bug.cgi?id=11031
--- Comment #21 from Shinichiro Hamaji <hamaji at chromium.org> 2009-11-17 22:08:48 PST ---
> 1. I am not talking about counters attached to the node being attached or
> detached but about the other nodes that may be affected.
Ah, I see.
> 2. You do not need to attach a node or detach it to cause restructuring of the
> tree, you just need to change the style of an existing node.
> See this example on how a counter hierarchy can be change without adding or
> removing nodes from the dom:
> http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/counter-increment-002.htm
So, I think my "FYI patch" is working. I confirmed my patch is working
for all CSS counter tests.
> Note: the setTimeout part is critical. If you directly call run from onLoad,
> everything works without any changes not even your landed patch is necessary,
> because the changes to the dom are done before any counters or renderers are
> created and that case is covered (with some errors) by the previous code.
Yeah, I know this. I confirmed the test was failing without my patch
when I landed the patch. Note that counterValueForElementById calls
updateLayout so I didn't need setTimeout.
> The real question is how much slower?
I think my "FYI patch" is working without traversal. I guess you can
add
if (!renderer->style()->counterDirectives() || renderer->isAnonymous())
return;
into the top of updateCounters so that your patch won't make
non-counter-sites slower.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list