[webkit-dev] About fixing "old" layout bugs

[Dirk Pranke]

One admittedly painful way to do this would be to dump two render
trees, an old format and a new format, and then build tooling to roll
between the versions. Most of the pain would probably be in modifying
the dump code to accept version flags and know whether to output old
or new as necessary.

Of course, you can't really do this for pixel tests, so you're still
kind of stuck.

ref tests might be a  better answer in both situations.

-- Dirk

On Fri, Jun 4, 2010 at 10:36 AM, David Hyatt <hyatt at apple.com> wrote:
> In fact the (really lousy) model I've employed in the past when this
> situation has arisen is that I hack the render tree dump to continue to dump
> the old rendering.  The render tree dumping code is full of hacks as a
> result and is basically lying about many things at this point.
> It would be really nice to take the time to remove all of these hacks and
> just update every test, but we need a good solution for how to update many
> tests without breaking the tree.
> dave
> On Jun 3, 2010, at 6:16 PM, Ojan Vafai wrote:
>
> When there are only a couple tests that need new expectations, you can get
> away with committing your patch with the expectations for the platforms you
> have access to and then immediately grabbing the new expectations off the
> buildbots.
>
> There is currently no good way to address the cases where your patch causes
> many tests to need new results. There are ideas to make it better, but I
> don't think anyone is actively working on them. Specifically, the EWS bots
> could run the layout tests and give you access to the results.
> For now, with patches where you need to change many results and they're
> different on different platforms, you need to either get access to that
> platform, or get the help of someone who has access to it.
> Ojan
>
> On Wed, Jun 2, 2010 at 7:32 PM, Xianzhu Wang <phnixwxz at gmail.com> wrote:
>>
>> Hi,
>> I'm still wondering what the best practice is to deal with many updated
>> layout tests in a patch. It seems I must run the layout tests on all
>> effected platforms by myself to ensure a green build after committing the
>> patch, right? This is really difficult to me. Is there a easier way?
>> Thanks,
>> Xianzhu
>>
>> 2010/6/2 Xianzhu Wang <phnixwxz at gmail.com>
>>>
>>> Hi,
>>> 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>
>>> (https://bugs.webkit.org/show_bug.cgi?id=37261)
>>>   * relative font-size (https://bugs.webkit.org/show_bug.cgi?id=18413)
>>>   * line breaking around some punctuations
>>> (https://bugs.webkit.org/show_bug.cgi?id=37698)
>>> 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 fixing?
>>> 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?
>>> Thanks,
>>> Xianzhu
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>