[Webkit-unassigned] [Bug 11031] Another crazy counters bug

[bugzilla-daemon at webkit.org]

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





--- Comment #22 from Carol Szabo <carol.szabo at nokia.com>  2009-11-18 16:03:21 PST ---
> > The real question is how much slower?
> 
> I think my "FYI patch" is working without traversal. I guess you can
> add

I looked at your patch and I did not see how it could possibly handle a case
like this
<el1>
  ...
  <el2 style="counter-reset: c;">
     ...
  </el2>
  ...
</el1>

Now let's say that el1's style is changed to "counter-increment: c;"
This will cause this counter to be a root counter in a totally new counter
tree.
Without traversing all children of el1 to verify whether they have counters for
c, I do not know how to figure that these counters are now children of the
counter on el1.

> 
> if (!renderer->style()->counterDirectives() || renderer->isAnonymous())
>     return;
> 
> into the top of updateCounters so that your patch won't make
> non-counter-sites slower.

This will not work, because I came across a case where a whole tree is attached
at once to the document, and the root of the tree has no counters, but one of
the children has (I believe the case is <el class="use" /> where use:before is
"content-counter: c", so el is inserted in the tree with its child renderers
for before. el itself has no counter directives but the before child has and
requires update. One can argue that this is done automatically when
originalText() is called, but that does not work, because the counter may be
created before, when the style was set on the child which appeared attached to
the tree, and now it only needs an update. originalText() can not do that.

I finally figured out the counterValueFromElementById function and why it
crashed on me at some point, so I can submit now proper tests.

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