RESOLVED FIXED293179
v8.dev: wrong height for span in grid listing
https://bugs.webkit.org/show_bug.cgi?id=293179
Summary v8.dev: wrong height for span in grid listing
Ahmad Saleem
Reported 2025-05-17 07:52:57 PDT
Hi Team, Going through random website, I came across another Web Compat issue, so raising it now. Website Link: https://v8.dev/features/explicit-resource-management#explicit-resource-management-support *** Steps to Reproduce *** 1) Open above article 2) Try to hover over image icons of Chrome, Mozilla etc and notice that `hover` does not cover full container height *** Expected Result *** Hover color cover full container width and height and width should be more square rather than elongated one. *** Actual Result *** Height is 172px while width is 146px in Safari while in Chrome, it is 146 x 146 (removing subpixel deliberately here). *** Other browsers *** Chrome Canary 138.0.7184.0 (Official Build) canary (arm64) - Works Safari 18.5 - Does not work WebKit ToT (295054@main) - Does not work Firefox Nightly 140 (20250516092940) - Works Ladybird (b559965448e37e68f52d119ba0aea0b3f94a0f7f) - hover color is different but height and width works. Just raising, so we can fix it. Thanks!
Attachments
Safari (Broken) Reference Screenshot (231.60 KB, image/png)
2025-05-17 07:54 PDT, Ahmad Saleem
no flags
Testcase (309 bytes, text/html)
2025-05-27 16:45 PDT, Sammy Gill
no flags
rendering in safari, firefox, chrome (726.36 KB, image/png)
2025-05-27 20:17 PDT, Karl Dubost
no flags
[fast-cq]Patch (7.18 KB, patch)
2025-06-04 07:43 PDT, alan
no flags
Ahmad Saleem
Comment 1 2025-05-17 07:54:08 PDT
Created attachment 475282 [details] Safari (Broken) Reference Screenshot
Radar WebKit Bug Importer
Comment 2 2025-05-19 17:54:34 PDT
Karl Dubost
Comment 3 2025-05-20 00:16:32 PDT
Icons are in a grid applied to a ul/li setup. <ul class="feature-support"> <li class="environment has-link has-support"> <a href="https://chromestatus.com/feature/5071680358842368"> <span class="icon chrome">Chrome:</span> <span class="support">supported since version <span class="version">134</span> </span> </a> </li> … </ul> .feature-support { grid-gap: .5em; background: var(--main-background-color); display: grid; grid-template-columns: 1fr 1fr 1fr 1fr 1fr; margin-bottom: .5em; padding-left: 0; } the hover is applied to the anchor, not the li element. footer a:focus, footer a:hover, main a:focus, main a:hover { background-color: #0a50c2; background-color: var(--main-and-footer-link-color); color: #fff; color: var(--main-background); } The li doesn't adjust its height to the full height of the anchor.
Karl Dubost
Comment 4 2025-05-20 00:18:36 PDT
OK reduced test case: https://codepen.io/webcompat/pen/wBBbNxE ul { width: 500px; background-color: gold; display: grid; grid-template-columns: 1fr 1fr 1fr 1fr 1fr; } li { background-color:pink; border: 2px solid red;} span { display:block; padding: 100% 0 0} <ul> <li><span> </span></li> <li><span> </span></li> <li><span> </span></li> <li><span> </span></li> <li><span> </span></li> </ul>
Karl Dubost
Comment 5 2025-05-20 00:19:02 PDT
There is probably an already existing bug about that.
Sammy Gill
Comment 6 2025-05-27 16:45:40 PDT
Created attachment 475391 [details] Testcase Attaching further reduced test case
Sammy Gill
Comment 7 2025-05-27 16:49:19 PDT
From a bit of debugging it doesn't quite seem to be a grid issue. You can achieve the same bug by removing display: grid from the ul. A render tree dump seems to give the following B---YLC--L --* RenderView at (0,0) size 2560x1356 renderer (0x134238150) layout box (0x0) B----L---L -- HTML RenderBlock at (0,0) size 2560x150 renderer (0x1341ec230) layout box (0x0) node (0x1340ac6a0) B--------- -- BODY RenderBody at (8,16) size 2544x118 renderer (0x1341ec3a0) layout box (0x0) node (0x1340ac730) (layout overflow 0,0 2544x118) (visual overflow 0,-1 2544x120) B--------L -- UL RenderGrid at (0,0) size 140x118 renderer (0x15a380000) layout box (0x0) node (0x1342e4340) (layout overflow 0,0 140x118) (visual overflow 0,-1 141x120) B--------L -- LI RenderListItem at (40,0) size 100x118 renderer (0x1343e4100) layout box (0x0) node (0x1340ac7c0) (layout overflow -17,0 117x118) (visual overflow -17,-1 118x120) B---Y----- -- RenderBlock at (0,0) size 100x18 renderer (0x1341ec680) layout box (0x13423c340) (layout overflow -17,0 117x18) (visual overflow -17,0 117x18) -- line at (0.00,0.00) size (100.00x18.00) baseline (14.00) enclosing top (0.00) bottom (18.00) -- Root inline box at (0.00,0.00) size (0.00x18.00) -- Run(s): -- Atomic box at (-17.00,0.00) size 7.00x18.00 renderer->(0x1341e8380) I---Y----- -- RenderListMarker (::marker) at (-17,0) size 7x18 renderer (0x1341e8380) layout box (0x13423c410) B--------- -- SPAN RenderBlock at (0,18) size 100x100 renderer (0x1341ec510) layout box (0x0) node (0x1340ac850) (layout overflow 0,0 100x100) (visual overflow -1,-1 102x102) The extra spacing at the top looks like it is coming from the fact that the list item is computing its height from its contents and the list marker content adds to it. Adding list-style: none; to the ul causes us to size the list item the same as other engines
Karl Dubost
Comment 8 2025-05-27 20:17:11 PDT
Created attachment 475394 [details] rendering in safari, firefox, chrome
Karl Dubost
Comment 9 2025-05-27 20:22:06 PDT
interesting looking at https://searchfox.org/wubkat/source/Source/WebCore/rendering/RenderListMarker.cpp I have seen https://searchfox.org/wubkat/rev/a7ddc6651da8ec6a5337847fae050ddf658db1b7/Source/WebCore/rendering/RenderListMarker.cpp#424-429 ```cpp LayoutUnit RenderListMarker::lineHeight(bool firstLine, LineDirectionMode direction, LinePositionMode linePositionMode) const { if (!isImage()) return m_listItem->lineHeight(firstLine, direction, PositionOfInteriorLineBoxes); return RenderBox::lineHeight(firstLine, direction, linePositionMode); } ``` So I tried `line-height: 0`. This is also fixing the issue for Safari.
alan
Comment 11 2025-06-04 07:43:19 PDT
Created attachment 475476 [details] [fast-cq]Patch
EWS
Comment 12 2025-06-04 09:35:34 PDT
Committed 295819@main (7352a31480b4): <https://commits.webkit.org/295819@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 475476 [details].
Note You need to log in before you can comment on or make changes to this bug.