Bug 232913 – [GLIB] Update test expectations and baselines after r284521

• Component: New Bugs
• Status: RESOLVED FIXED

[Arcady Goldmints-Orlov]

[GLIB] Update test expectations and baselines after r284521

[Arcady Goldmints-Orlov]

Created attachment 443746 [details]
[fast-cq] Patch

[Diego Pino]

I think we should reach an agreement soon about the divergence created by interpreting tests as xhtml while other ports treat them as html.

For instance, in this patch several tests get their baseline updated because the resulting layout in those tests have changed. But at the same time, the labels in the render tree are now posted as xhtml tags.

If at some point the GTK/WPE baselines produce the same layout as the general baseline, the baselines will still be different because of the xhtml labels in the render tree. This means is going to be more and more difficult to detect when two baselines become equal again and merge them. Also, we're implying it's Ok to emit new baselines when the only difference between two results are the xhtml/html tags. And I think we don't want to do that, right?

I think we need to clarify what's our policy and what we are going to do regarding this issue before going further.

[EWS]

Committed r285568 (244076@main): <https://commits.webkit.org/244076@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 443746 [details].

[Radar WebKit Bug Importer]

<rdar://problem/85243630>

[Martin Robinson]

(In reply to Diego Pino from comment #2)
> I think we should reach an agreement soon about the divergence created by
> interpreting tests as xhtml while other ports treat them as html.
> 
> For instance, in this patch several tests get their baseline updated because
> the resulting layout in those tests have changed. But at the same time, the
> labels in the render tree are now posted as xhtml tags.
> 
> If at some point the GTK/WPE baselines produce the same layout as the
> general baseline, the baselines will still be different because of the xhtml
> labels in the render tree. This means is going to be more and more difficult
> to detect when two baselines become equal again and merge them. Also, we're
> implying it's Ok to emit new baselines when the only difference between two
> results are the xhtml/html tags. And I think we don't want to do that, right?
> 
> I think we need to clarify what's our policy and what we are going to do
> regarding this issue before going further.

Sorry. I missed this comment. I did a cq+ here just in the interest of getting the build bots green. There are three new baselines here:

* LayoutTests/platform/glib/svg/foreignObject/background-render-phase-expected.txt
* LayoutTests/platform/glib/svg/foreignObject/multiple-foreign-objects-expected.txt
* LayoutTests/platform/glib/svg/wicd/sizing-flakiness-expected.txt

When the sniffing issue is fixed, let's explicitly see if we can remove these baselines.

[Arcady Goldmints-Orlov]

My motivation for creating these new baselines was to attempt to maintain some test coverage while the underlying issue is being worked on. I think there is a balance to be had between marking things as failing and maintaining test coverage, and in cases where the "new" result is not an error and not obviously wrong, I have opted to rebaseline rather than mark the test as failing and lose that coverage.