Bug 232913 - [GLIB] Update test expectations and baselines after r284521
Summary: [GLIB] Update test expectations and baselines after r284521
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Arcady Goldmints-Orlov
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-11-09 16:07 PST by Arcady Goldmints-Orlov
Modified: 2021-11-10 09:40 PST (History)
4 users (show)

See Also:


Attachments
[fast-cq] Patch (41.28 KB, patch)
2021-11-09 16:11 PST, Arcady Goldmints-Orlov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Arcady Goldmints-Orlov 2021-11-09 16:07:22 PST
[GLIB] Update test expectations and baselines after r284521
Comment 1 Arcady Goldmints-Orlov 2021-11-09 16:11:30 PST
Created attachment 443746 [details]
[fast-cq] Patch
Comment 2 Diego Pino 2021-11-09 23:57:23 PST
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.
Comment 3 EWS 2021-11-10 00:49:05 PST
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].
Comment 4 Radar WebKit Bug Importer 2021-11-10 00:50:22 PST
<rdar://problem/85243630>
Comment 5 Martin Robinson 2021-11-10 00:56:26 PST
(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.
Comment 6 Arcady Goldmints-Orlov 2021-11-10 09:40:20 PST
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.