[webkit-dev] About fixing "old" layout bugs
phnixwxz at gmail.com
Sat Jul 31 17:33:07 PDT 2010
Now the status of the three old bugs are:
* white space preceding <br> (https://bugs.webkit.org/show_bug.cgi?id=37261):
New patches uploaded
* relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413): New
* line breaking around some punctuations (
For the <br> bug, I still split the patch into following parts to ease
1. A patch containing only the changed code and the added test;
2. A patch containing all affected text-only layout tests that differ only
about trailing spaces;
3. A patch containing all affected DRT layout tests that differ only about
trailing spaces of text rendering nodes;
4. A patch containing other layout tests that have been manually adjusted;
5. A patch containing changed Skipped files of other platforms.
The above 2 and 3 were auto generated by scripts. And instead of rebaslining
tests of other platforms, I simply (temporarily) added the affected tests
into Skipped files. I used the similar method to generate the patch for the
second bug but didn't split it because the patch is much smaller. The
patches also don't contain pixel tests to reduce the scope and size.
Because of rapid changes of affected layout tests, the patches had already
been out-dated even before I uploaded them. It seems to me that the normal
process of review queue and commit queue doesn't work for such patches.
Would any committer please help review and maybe commit the patches?
2010/6/2 Xianzhu Wang <phnixwxz at gmail.com>
> I'm new to webkit development, and I'd like to hear opinions about the
> problems I met.
> Now I'm trying to fix some "old" layout bugs, for example:
> * white space preceding <br> (
> * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
> * line breaking around some punctuations (
> Some people have warned me about the difficulty of fixing these bugs, and
> now I have realized it. Fixing the bugs themselves is not very difficult,
> for example, only 2 functional lines change can fix the first bug. However,
> the change will break more than 4000 existing layout tests mostly because
> trailing spaces preceding <br>s in current expectations of the tests (for
> example, "PASS " vs "PASS"). I tried to rebaseline all effected layout tests
> (for now on mac only), and the patch is about 6MB (Sorry I overlooked the
> "Bigfile" option when I submitted the patch, so I split it into 4 parts).
> My questions are:
> 1. The bugs violate the standards and cause some site compatibility issues.
> However, because the bugs are old, some web developers might treat them as
> features and depend on them, so fixing them might break some existing pages.
> Is there any existing policy about this problem? Are these bugs worth
> 2. What's the best practice to deal with a patche containing many updated
> layout test expectations? Is there a good way to rebaseline the effected
> tests on all platforms?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev