In ports that use CoordinatedGraphics, WebKitTestRunner do not use "UseFixedLayout" option except for certain directories. For those exceptions directories, tests are run only with "UseFixedLayout". Choosing between "UseFixedLayout" or not affects the code path used for final painting, so its useful to be able to do pixel testing in both cases if we want to keep the two code paths working.
Ideas: - add an option / way to run tests always using UseFixedLayout when running layouttests. - move one of the ports using CoordinatedGraphics to always test with this codepath: this will increase our overall coverage. The drawback is that many features are behind reducing the number of layout tests that will pass, but if the ports use case is focused around "UseFixedLayout" I think this is a better choice in the long run. Comments? :)
Maybe it worth to take a look at https://bugs.webkit.org/show_bug.cgi?id=102517 When implementing support for viewport properties I've had a conversation with Thiago who pointed me to this patch. It enables an option (--css-device-adaptation) to run WebKitTestRunner with fixedlayout support. I didn't replicate this option on Nix because of time constraints.
(In reply to comment #2) > When implementing support for viewport properties I've had a conversation with Thiago who pointed me to this patch. It enables an option (--css-device-adaptation) to run WebKitTestRunner with fixedlayout support. I counted it as the "exceptional directories" in the bug description. But I think we need to figure out a way to cover more cases without negatively impacting the current coverage. Technically is a matter of knowing WHEN/WHERE we make shouldUseFixedLayout() return true.
(In reply to comment #1) > - move one of the ports using CoordinatedGraphics to always test with this codepath: this will increase our overall coverage. The drawback is that many features are behind reducing the number of layout tests that will pass, but if the ports use case is focused around "UseFixedLayout" I think this is a better choice in the long run. Fixed layout basically tells the FrameView to stop doing a part of what it usually does. Testing with this would the mechanisms of higher layers handling those delegated responsibilities, especially regarding scrolling and painting. The issue is that each port has its own set of layers on top to handle those things, and I'm wondering if it's realistic to expect the same behavior from all of them. The risk I see with this is that if all CoordinatedGraphics ports switch to this kind of testing, our test expectations can diverge from the rest of WebKit. I don't know how many tests would be failing with this, it depends, but if there are many of them, I think that we should allow our main bots to test the same behaviors as other ports. Do you know if the android bot is testing with enableFixedLayoutMode(true)?