| Summary: | REBASELINE: [ iPadOS16 ] imported/w3c/web-platform-tests/css/css-cascade/all-prop-initial-xml.html is constantly failing | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Hercules Hjalmarsson <hhjalmarsson> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | bfulgham, karlcow, koivisto, simon.fraser, webkit-bot-watchers-bugzilla, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Hercules Hjalmarsson
2022-09-28 15:51:39 PDT
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. |