Created attachment 460521 [details] example page After https://github.com/WebKit/WebKit/commit/e7abdadb1b69209d90e51b46caab32d4cc6bb093 the top border of the image grid is outside of the viewport. I can reproduce it on all platforms.
Created attachment 460522 [details] before - border visible
Created attachment 460523 [details] after - border is not in the viewport
<rdar://problem/96083869>
This looks like a quite serious regression, should the patch be reverted for now?
(In reply to Yury Semikhatsky from comment #4) > This looks like a quite serious regression, should the patch be reverted for > now? Yes, I believe so.
The patch has been reverted and I will work on the original bug report again. Thanks for the report Yury!
Hi Yury, We have been trying to reproduce this issue but have been unsuccessful so far. Would you be able to provide us with additional information on what you did to produce the issue? Any additional information on the steps you took along with information regarding the environment in which the tests ran (e.g. if you had 1x display) would be helpful in tracking down the problem. Since the code changes were related to rendering replaced elements, would you be able to provide us with some details on the images that were used? It would be nice to try to recreate our test case as close as possible to the one you ran.
(In reply to Sammy Gill from comment #7) > Hi Yury, > > We have been trying to reproduce this issue but have been unsuccessful so > far. Would you be able to provide us with additional information on what you > did to produce the issue? Any additional information on the steps you took > along with information regarding the environment in which the tests ran > (e.g. if you had 1x display) would be helpful in tracking down the problem. > I reproduced it in playwright builds on mac (with dpr=2) and on linux (WPE) with dpr=1. Let me try to reproduce it with stock MiniBrowser. > Since the code changes were related to rendering replaced elements, would > you be able to provide us with some details on the images that were used? It > would be nice to try to recreate our test case as close as possible to the > one you ran. Sorry about that, attaching .zip file with all the images.
Created attachment 460564 [details] test page
(In reply to Yury Semikhatsky from comment #8) > (In reply to Sammy Gill from comment #7) > > Hi Yury, > > > > We have been trying to reproduce this issue but have been unsuccessful so > > far. Would you be able to provide us with additional information on what you > > did to produce the issue? Any additional information on the steps you took > > along with information regarding the environment in which the tests ran > > (e.g. if you had 1x display) would be helpful in tracking down the problem. > > > > I reproduced it in playwright builds on mac (with dpr=2) and on linux (WPE) > with dpr=1. Let me try to reproduce it with stock MiniBrowser. > I can reproduce it with MiniBrowser on macOS (default resolution on m1 macbook pro) and Linux GTK. I can't reproduce it with ./Tools/Scripts/run-safari though.
Created attachment 460582 [details] macos
Created attachment 460583 [details] gtk
Does anyone know if there is a WPT that covers this behavior? It's surprising that the blamed change passes all tests, but exposes this problem. Clearly we have a lack of test coverage here -- it would be good to identify a suitable test and make sure we start tracking it.
This change must have exposed some other (non-layout) bug in Webkit. Setting margin on the body reveals the top border, while it should make no difference -when it comes to laying out/painting a replaced _border_ box. Quite a mystery.
If the top border is more than 1px tall does it hide the entire border, or just a 1px sliver?
(In reply to Simon Fraser (smfr) from comment #15) > If the top border is more than 1px tall does it hide the entire border, or > just a 1px sliver? border-width: 1.5px produces a hairline border on 2x (so always hides 1px).
Since I can reproduce the bug now and it seems like I have enough information to move forward with this, I am going to resolve this bug report once again. The patch has already been reverted so I will continue on the original bug (206161). I agree that we should have a test case for this so I will try to add one once I can find the underlying bug. Sorry for reopening I believe this should be the last time.