Bug 245803 – REBASELINE: [ iPadOS16 ] imported/w3c/web-platform-tests/css/css-cascade/all-prop-initial-xml.html is constantly failing

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Hercules Hjalmarsson]

imported/w3c/web-platform-tests/css/css-cascade/all-prop-initial-xml.html

Is a constant text failure on iPadOS ToT and since introduced on the queue. It appears that it could possibly be a rebaseline issue. However, this is passing on iOS16 with the exact same expected output. Verifying before rebaselining.

HISTORY:
https://results.webkit.org/?suite=layout-tests&test=imported/w3c/web-platform-tests/css/css-cascade/all-prop-initial-xml.html

DIFF:
@@ -383,9 +383,9 @@
 PASS -webkit-mask-position-y
 PASS -webkit-mask-source-type
 PASS -webkit-nbsp-mode
-PASS -webkit-overflow-scrolling
 PASS -webkit-rtl-ordering
 PASS -webkit-ruby-position
+PASS -webkit-tap-highlight-color
 PASS -webkit-text-combine
 PASS -webkit-text-fill-color
 PASS -webkit-text-security

[Radar WebKit Bug Importer]

<rdar://problem/100531878>

[Hercules Hjalmarsson]

This issue can be reproduced by using command:

run-webkit-tests --iterations=2  --ipad-simulator  imported/w3c/web-platform-tests/css/css-cascade/all-prop-initial-xml.html

[EWS]

Test gardening commit 254980@main (663c5a893e60): <https://commits.webkit.org/254980@main>

Reviewed commits have been landed. Closing PR #4817 and removing active labels.

[Alexey Proskuryakov]

This is a very weird failure. Why would iPadOS 16 lose -webkit-overflow-scrolling and gain -webkit-tap-highlight-color? 

Is there some crazy off-by-one bug in CSS implementation, or in the test?

[Karl Dubost]

(for memories)
all the all-prop-initial-xml-expected.txt
https://searchfox.org/wubkat/search?q=all-prop-initial-xml-expected.txt&path=&case=false&regexp=false

[Sam Sneddon [:gsnedders]]

(In reply to Alexey Proskuryakov from comment #4)
> This is a very weird failure. Why would iPadOS 16 lose
> -webkit-overflow-scrolling and gain -webkit-tap-highlight-color? 
> 
> Is there some crazy off-by-one bug in CSS implementation, or in the test?

-webkit-overflow-scrolling is dependent on desktop mode v. mobile mode at least (and I can't remember which mode iPadOS tests run in by default), but -webkit-tap-highlight-color should exist iff WebKit is built with touch events enabled.

[Hercules Hjalmarsson]

This doesn't appear to be a simple re-baseline.

When running this locally (After getting the bot actual output as baseline). I'm getting,

DIFF:
@@ -387,6 +387,7 @@
 PASS -webkit-nbsp-mode
 PASS -webkit-rtl-ordering
 PASS -webkit-ruby-position
+PASS -webkit-tap-highlight-color
 PASS -webkit-text-combine
 PASS -webkit-text-fill-color
 PASS -webkit-text-security


webkit-tap-highlight-color appears to be found when running this locally with rwt compared to running this on the bot. Just re-baselining this for the bots would result in it still failing when running locally.

[Hercules Hjalmarsson]

Setting expectation temporarily while this is being looked at.

[EWS]

Test gardening commit 255807@main (1aa789f3371b): <https://commits.webkit.org/255807@main>

Reviewed commits have been landed. Closing PR #5607 and removing active labels.

[Hercules Hjalmarsson]

The webkit-tap-highlight-color issue is due to build differences.

When running this with a Opensource build (similar to the bots) it's not appearing in the output. Like Sam mentioned, this issue is related to how our WebKit builds are built.

[EWS]

Test gardening commit 255846@main (73179f061bf2): <https://commits.webkit.org/255846@main>

Reviewed commits have been landed. Closing PR #5646 and removing active labels.

[Hercules Hjalmarsson]

(In reply to EWS from comment #11)
> Test gardening commit 255846@main (73179f061bf2):
> <https://commits.webkit.org/255846@main>
> 
> Reviewed commits have been landed. Closing PR #5646 and removing active
> labels.

The rebaseline in above commit will at least resolve this on Opensource.