Bug 254595

Summary: display: flex element not ignore font (content) like as other browser engines.
Product: WebKit Reporter: Józsa Márton <morfyum>
Component: Layout and RenderingAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, changseok, esprehn+autocc, ews-watchlist, glenn, karlcow, koivisto, kondapallykalyan, pdr, simon.fraser, webkit-bug-importer, wenson_hsieh, zalan
Priority: P2 Keywords: BrowserCompat, HTML5, InRadar
Version: Safari 16   
Hardware: All   
OS: All   
URL: https://morfyum.github.io/maincss/
Attachments:
Description Flags
Test reduction
none
Patch
none
Screenshot with the fix none

Józsa Márton
Reported 2023-03-28 09:15:42 PDT
Hello! I have a proof of concept code, you can test this. ## The problem: By default, flexbox elements ignore font-size and/or text in div on Chrome and Firefox. <- Bug in chrome/chromium and firefox based browsers? This is the problem for which required 26px margin-top in .header-flex-dropdown (block elements has no this issue) On webkit browsers, show this extra 26 pixel (as bug), because not ignore hidden (display: none) element font/content size <- BUG in webkit? I open an issue in my repo: This is contain: 1. The problem description 2. The code parts what cause the problem https://github.com/morfyum/maincss/issues/2 ## Proof of Concept code: https://morfyum.github.io/maincss/ > Click on [ Templates ] drop down menu in header on chrome/firefox and Safari. Please check the difference. - Dropdown menu work without issue on Chrome, and Firefox (Linux, android, and mac) - Dropdown menu show extra pixels (from not ignored font size) on Safari(OSX) and Epiphany(linux) (probably any webkit based browser) Header work on all platform, all browser well instead of webkit based browsers: Safari(macos), Epiphany(linux). I don't know is this a bug in blink and spidermonkey, or in a webkit engine. I think webkit handles it more logically, but other browser engines don't think so. Thanks for reading.
Attachments
Test reduction (429 bytes, text/html)
2023-03-28 20:22 PDT, zalan
no flags
Patch (5.14 KB, patch)
2023-03-30 07:59 PDT, zalan
no flags
Screenshot with the fix (1.43 MB, image/png)
2023-03-30 10:56 PDT, zalan
no flags
zalan
Comment 1 2023-03-28 20:22:26 PDT
Created attachment 465651 [details] Test reduction
Radar WebKit Bug Importer
Comment 2 2023-03-28 20:23:27 PDT
zalan
Comment 3 2023-03-28 20:33:05 PDT
interestingly we recover when forcing in-flow on the flex item. document.body.offsetHeight; show_this.classList.toggle("show"); document.body.offsetHeight; show_this.style.position = "static"; document.body.offsetHeight; show_this.style.position = "absolute";
zalan
Comment 4 2023-03-28 21:04:21 PDT
We construct the following tree structure for the flexbox: B-------- -- DIV RenderFlexibleBox at (0,0) size 1185x20 B---YG--- -- RenderBlock at (0,0) size 21.61x20 I-------- -- #text RenderText ("PASS if no") BA----L-- -- DIV RenderBlock at (8,22) size 21.61x14 I-------- -- #text RenderText ("gap.") (note that the incorrectly positioned out-of-flow box is nested inside the anon flex item) When the incorrectly positioned out-of-flow box starts as: position: absolute; (or use the "recover case" above at comment #3) we've got the following tree structure for the flexbox: B-------- -- DIV RenderFlexibleBox at (0,0) size 1185x20 B-------- -- DIV RenderBlock at (0,0) size 21.61x20 I-------- -- #text RenderText ("PASS if no") BA----L-- -- DIV RenderBlock at (8,8) size 21.61x14 I-------- -- #text RenderText ("gap.") (note that now the out-of-flow box is a sibling to the flex item) We also seem to produce the same structure when the text content ("Pass if...") is nested inside a block container (<div>PASS if no</div>) It looks like the incorrect rendering is actually caused by this incorrect tree structure.
zalan
Comment 5 2023-03-30 07:59:35 PDT
EWS
Comment 6 2023-03-30 10:52:25 PDT
Committed 262341@main (3906ca99d0cf): <https://commits.webkit.org/262341@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 465679 [details].
zalan
Comment 7 2023-03-30 10:56:14 PDT
Created attachment 465682 [details] Screenshot with the fix
zalan
Comment 8 2023-03-30 10:57:56 PDT
Thank you for filing this issue. It is fixed now on trunk (I am a bit puzzled by what "Árvíztűrő tükörfúrógép" is :).
Note You need to log in before you can comment on or make changes to this bug.