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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 17 08:41:04 PST 2009


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





--- Comment #20 from Carol Szabo <carol.szabo at nokia.com>  2009-11-17 08:41:04 PST ---
> I'm not sure if the B2 can be an issue. I thought changing location
> requires DOM nodes detach/attach and render objects will be
> destructed/constructed. Please correct me if my understanding is
> wrong. It's very nice if you post an HTML where B2 is an issue.
1. I am not talking about counters attached to the node being attached or
detached but about the other nodes that may be affected.
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

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.

> Anyway, even if B2 is really an issue, I don't think calling
> updateCounters() for all add-child is good deal as counter is rarely
> used. This would make all website, which insert DOM nodes, slower even
> if they don't use counter at all.
The real question is how much slower?
If there is only one node inserted all updateCounters does is check the node's
style for counter directives and verify that the node does not have children
and it returns. To me this isn't much overhead.
If a hierarchy of nodes is inserted at one time (as it is sometimes the case in
the examples from w3.org) updateCounters checks all those nodes for
counterDirectives and if none is found it does nothing more.
Only if counter directives are found, the algorithm becomes more complex.
If anyone has a better idea please state it I am more than happy to use it as
long as it works.
Right now I have a working solution. The only problem is with the test cases,
because despite QtLauncher displaying the proper counter values and
DumpRenderTree dumping the proper tree, counterValueForElementById sometimes
crashes and some other times returns an empty string instead of the proper
counter value.
I believe that for the moment I shall submit a patch with the accompanying
tests in normal dump mode, and then I shall fix DumpRenderTree in a separate
patch.

-- 
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