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
<rdar://problem/100531878>
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
Test gardening commit 254980@main (663c5a893e60): <https://commits.webkit.org/254980@main> Reviewed commits have been landed. Closing PR #4817 and removing active labels.
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?
(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®exp=false
(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.
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.
Setting expectation temporarily while this is being looked at.
Test gardening commit 255807@main (1aa789f3371b): <https://commits.webkit.org/255807@main> Reviewed commits have been landed. Closing PR #5607 and removing active labels.
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.
Test gardening commit 255846@main (73179f061bf2): <https://commits.webkit.org/255846@main> Reviewed commits have been landed. Closing PR #5646 and removing active labels.
(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.