Created attachment 119090 [details] Chrome test extension When an empty beforeLoad handler is inserted into a page (for example by an extension), a part of the page can be incorrectly aligned. Verified to be broken in WebKit r102684 on Windows 7 Reproduction steps: 1. Install attached extension (if you use Chrome). Otherwise, create an extension that uses this code in it's content script: document.addEventListener("beforeload", function(event) {}, true); Alternatively, you could use the AdBlock extension (http://safariadblock.com/) instead, although it's beforeload handler is not empty. 2. navigate to http://highslide.com/examples/gallery-horizontal-strip.html 3. click the first image 4. notice the bottom (navigation) bar is shifted to the right. 5. remove the extension and repeat steps 2, 3 and 4 and notice the issue has gone away. Expected: the bottom navigation bar should be centered Instead: the bottom bar is shifted to the right as if it was centered before it had it's size being applied (in that case it's a possible side effect of fixed bug 45586)
Created attachment 119168 [details] Minimized test case I can confirm the bug, minimized test case (no longer requiring an extension) is attached. Took me a while to figure this out but what this site does apparently: * It preloads thumbnail images. * When the user clicks an image it fills the thumbnail row with new images using the same src as for preloaded images. * It expects the offsetWidth for the thumbnail row to be correct immediately after inserting the images. It's that last step that fails - if a beforeload event handler is present the width is reported as if the width of all images were zero. That's what the testcase demonstrate: if you create a copy of a preloaded image and insert it into a table then the reported offsetWidth of the image container is usually immediately correct, not if you have a beforeload event listener however. The strange thing is: if you test img2.width you will get the correct value before offsetWidth of the container is accessed and zero afterwards. I guess that accessing offsetWidth triggers a reflow and something goes wrong there.
Sorry to bring this up from the dead, but is there a fix planned?
I am able to reproduce this bug in Safari 15.6 on macOS 12.5 on using attached test case and following instruction and by putting beforeload event, the image contain width becomes "2" rather than "102" as before and other browsers (Chrome Canary 106 and Firefox Nightly 105) does not change width even if event is added. Although it is fixed in Safari Technical Preview 151 and it does not change the image width. Since it is fixed, I am going to mark this "RESOLVED CONFIGURATION CHANGED". I don't know what fixed it but appreciate if someone can comment and share some input. Thanks!