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

[bugzilla-daemon at webkit.org]

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





--- Comment #13 from Carol Szabo <carol.szabo at nokia.com>  2009-11-06 12:38:09 PDT ---
(In reply to comment #12)
> > +        Tests: css2.1/counter-increment-002.html
> > +               css2.1/counter-reset-000.html
> > +               css2.1/counter-reset-002.html

These tests are actually copied from the css2.1 test battery and I maintained
the naming convention from there.
The only modification to the tests have to do with whitespace and indentation
and with making sure that DumpRenderTree waits for the timer to fire before it
dumps.
Do you still think that these tests need to be moved to fast/css/counters?

> Please make the new tests use dumpAsText if possible.

Unfortunately dumpAsText does not dumpCounterValues. So I was unable to have
the tests work that way. If anybody has an idea how to retrieve Counter values
from JS, I would try it that way, as I prefer dumpAsText myself since it is
less platform specific.

> Coding style mistakes here. There is a missing space after "if" and missing

I am sorry for the many style mistakes in this patch. I tried to hunt them down
to the best of my abilities and fixed what I found including what
check-webkit-style reported. Some of these files have many style errors and I
did not want to make the patch more confusing than it already is.
I'll do my best to fix the issues.
> > +    /* identifier must match the identifier of this counter or
> > +     * the renderers affected by this insertion shall not be
> > +     * invalidated.
> > +     */
> 
> We use "//" for comments, and sentences with capital letters and periods.

In a previous submission a reviewer (I believe that it was Tor Arne Vestb?)
made me change // to /* for function usage comments, I am not sure what is the
right way anymore.

> Looking forward to seeing some future iterations, hopefully in some smaller
> pieces.

It is hard to break this up since most changes depend on each other for proper
results, also Eric Seidel wants one patch per bug. I will do the following,
though:
1. I shall create a new bug and I shall submit the improvements to the debug
function as a separate patch for that bug.
2. I shall remove all code changes that are not affecting functionality, and
try to resubmit. Hopefully the patch will not look that big, because except for
the tests it should not have more than 100 lines or so.

1. I shall submit

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