Bug 300866 – Adding a CSS class which changes an element's flex through an !important rule does not work

• Component: Layout and Rendering
• Status: REOPENED

[Nige White]

Created attachment 477101 [details]
Demonstrates the bug

In the attached example the initial layout is as expected.

Click the 'Add "measuring" class' button. This adds a class which has a rule which overrides all others and makes all rows flex : 0 0 16.6% !important

There are six rows, so all rows should appear an equal height. There is no flex shrink or flex grow allowed, and the rule is !important and should override all normal rules.

They do *not* appear at an equal height of 16.6%

Click the "Show empty row's flex" button. It confirms that the computedStyle has the flex value as "0 0 max(16.666%, 0px)"

But the layout is not correct.

This works on Chrome and Firefox and Safari 18.

[Karl Dubost]

Created attachment 477102 [details]
rendering in safari, firefox, chrome

Thanks for the report.

[Nige White]

(In reply to Karl Dubost from comment #1)
> Created attachment 477102 [details]
> rendering in safari, firefox, chrome
> 
> Thanks for the report.

That's Rendering on Safari 18 I see there.

Try on an iPad which has been "up"graded to Safari 26

[Nige White]

Created attachment 477103 [details]
Rendering on Safari 26

[Karl Dubost]

That was rendering on STP Release 230 (WebKit 21623.1.11.19.3)
not Safari 18. :) More exactly


Safari Technology Preview  230  / 26.0          21623.1.11.19.3
Firefox Nightly            145.0a1       14525.10.7
Google Chrome Canary       143.0.7475.0  7475.0

[Karl Dubost]

but indeed it reproduces on iPad. and it goes back to normal after rotation.

[Nige White]

I changed the priority to blocker. Ascertaining correct measurements is important. Our app will not work without the flexbox layout working properly.

[Radar WebKit Bug Importer]

<rdar://problem/162977370>

[alan]

it has already progressed on trunk (300433@main)

[alan]

*** This bug has been marked as a duplicate of bug 299372 ***

[Nige White]

When will the fix be released?

I have had two updates of iOS on my iPad, and Safari still misrenders flexbox layouts.

Safari 18, and all the non-iOS browsers lay out fine. Just the layout engine of 26 is broken. This is affecting our business.

Flexbox has been around a long time. It has worked in Safari for a long time. How did you break it on version 26?

[Nige White]

Seems that this is not a duplicate of "Rendering issues" (Please use descriptive ticket names and descriptions)

[Nige White]

It works on Safari 26.1 on Mac.  It is BROKEN on iPad.

[Nige White]

This is a TERRIBLE bug.

Your flexbox implementation on iOS simply DOES. NOT. WORK.

In the Safari debugger, the elements just change size seemingly randomly. When I mouseover them in the debugging window, they flip to a correct height.

[Nige White]

Are you doing anything about this bug? SOME feedback would be welcomed.

[Sammy Gill]

Created attachment 477936 [details]
iOS 26.1 iPad Screen Recording

Here is a screen recording of the test page on an iPad with iOS 26.1. This seems to be different from what we saw on iOS 26. Can you confirm if this is the behavior your are expecting or provide a screen recording with with you are seeing and with the device and OS you are using?

[Nige White]

You can run a test page for yourself to see how broken it is

https://www.bryntum.com/products/calendar/examples/basic/

Go to the "Month" view.

This view is of course a six row flexbox. One row for each week.

Run it on Mac Safari it's fine. On Chrome it's fine, on FF it's fine.

On iOS Safari you can't even pinpoint a failure. It's unstable. If you open it in the debugger, the element change size unpredictably as you select them in the DOM tab.

[Nige White]

Actually use https://www.bryntum.com/products/calendar/examples/basic/?screenshot

The designers in their infinite wisdom place enormous margins round the demo Calendar which makes it a bad UX on an iPad. And will not hear a word said against it.

Adding ?screenshot makes it fit the viewport for generating the thumbs you see in the examples landing page, and this is how I often run it on iPad.

[Nige White]

NOPE It is broken on MacOS too.

A broken browser. Elements change height in an indeterminate manner while simply mouseovering a month view.

[Nige White]

Created attachment 478009 [details]
See the flexed row heights change as the mouse moves over an element.

getComputedStyle($0).flex

On that row always returns `0 0 max(16.666667%, 59px)`

We want to flex it to 1/6 height, but never drop below 59 high.

It is *unable* to do this reliably.

[Simon Fraser (smfr)]

Nige, what macOS version are you testing on? Also, please test in the latest Safari Tech Preview.

[Nige White]

26.2. Latest update arrived yesterday.

Just go to a month view in any Calendar example.

It just WILL NOT obey the flexBasis of `max(16.666667%, 59px)` which is consistently applied to the row elements.

The element sizes just flip around in a non-deterministic way as you examine the DOM debugger tab and poke around with styles.

[Simon Fraser (smfr)]

What about Safari Tech Preview (which will have more recent fixes)?

[Nige White]

I feel you are clutching at straws here rather than rolling your sleeves up!