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 Rendering

Assignee:

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:

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

Description Józsa Márton 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.

Comment 1 zalan 2023-03-28 20:22:26 PDT

Created attachment 465651 [details]
Test reduction

Comment 2 Radar WebKit Bug Importer 2023-03-28 20:23:27 PDT

<rdar://problem/107349290>

Comment 3 zalan 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";

Comment 4 zalan 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.

Comment 5 zalan 2023-03-30 07:59:35 PDT

Created attachment 465679 [details]
Patch

Comment 6 EWS 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].

Comment 7 zalan 2023-03-30 10:56:14 PDT

Created attachment 465682 [details]
Screenshot with the fix

Comment 8 zalan 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 :).