Created attachment 447272 [details] example page After https://github.com/WebKit/WebKit/commit/bdb68ddedc91dba21084068424ed93bf58f54f0c flex box children are shrunk to fit into the container where they previously would keep their size. Steps to reproduce: open attached example.html in a window 500x500 Previously: both frames would have width 300px After the change: each has width 242
Created attachment 447273 [details] Before
Created attachment 447274 [details] After
I guess you mean r286206 then in the title...
Does it happen if you use <div>s instead of iframes with embedded documents?
BTW I've just tried with ToT and I cannot reproduce the issue you mention. I resize the window and both boxes end up occupying the same space...
(In reply to Sergio Villar Senin from comment #5) > BTW I've just tried with ToT and I cannot reproduce the issue you mention. I > resize the window and both boxes end up occupying the same space... Ah OK I see it now, the layout seems inconsistent, sometimes they're equally sized but then you resize and one of the becomes larger.
(In reply to Sergio Villar Senin from comment #4) > Does it happen if you use <div>s instead of iframes with embedded documents? No, I can only reproduce it with iframes. Apparently there was some intrinsic min-width (don't see it in the inspector though).
According to [1] iframe has default width=300. Before the change when two iframes having 'flex-shrink:1' were put into a flex container with width=500 they would keep width 300 (iframe's default width was treated as min-width essentially) which was consistent with Chromium behavior. After the change they are both shrunk to respect 'flex-shrink:1'. I don't know whether this new behavior is correct by the spec but it definitely breaks some web pages. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe#attr-width
(In reply to Yury Semikhatsky from comment #8) > According to [1] iframe has default width=300. Before the change when two > iframes having 'flex-shrink:1' were put into a flex container with width=500 > they would keep width 300 (iframe's default width was treated as min-width > essentially) which was consistent with Chromium behavior. After the change > they are both shrunk to respect 'flex-shrink:1'. I don't know whether this > new behavior is correct by the spec but it definitely breaks some web pages. Thanks for the info. I have a patch for this issue, I'd love to hear more about those sites that are broken, just to double check that the fix works in the wild.
Created attachment 447606 [details] Patch
Note that I haven't included any test because I'm importing https://github.com/web-platform-tests/wpt/pull/32141 as soon as it lands in the WPT repo (I mean as part of this patch).
(In reply to Sergio Villar Senin from comment #11) > Note that I haven't included any test because I'm importing > https://github.com/web-platform-tests/wpt/pull/32141 as soon as it lands in > the WPT repo (I mean as part of this patch). You could include the tests in this patch, and they get reviewed here, and once you get them approved here, the WPT upstream PR gets approved automatically.
Comment on attachment 447606 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=447606&action=review > Source/WebCore/ChangeLog:12 > + regression. Is there no other cases of replaced elements that need SVG images like behavior?
(In reply to Manuel Rego Casasnovas from comment #12) > (In reply to Sergio Villar Senin from comment #11) > > Note that I haven't included any test because I'm importing > > https://github.com/web-platform-tests/wpt/pull/32141 as soon as it lands in > > the WPT repo (I mean as part of this patch). > > You could include the tests in this patch, and they get reviewed here, and > once you get them approved here, the WPT upstream PR gets approved > automatically. The last time I tried the exporter it failed due to naming. In webkit the reference has -expected suffix while WPT expects -ref suffix. That's why I preferred to upload it to WPT and once landed I'll include it in this patch.
(In reply to Manuel Rego Casasnovas from comment #13) > Comment on attachment 447606 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=447606&action=review > > > Source/WebCore/ChangeLog:12 > > + regression. > > Is there no other cases of replaced elements that need SVG images like > behavior? No that I know of. The original patch had initially the code that I'm changing now. At the very last minute I decided to generalize it a bit thinking that replaced elements were basically just images without realizing that things like iframes were also replaced elements. For the rest of the images (raster images) they have intrinsic dimensions (1024x768, etc...). The thing with vector graphics (like SVG) is that they're scale independent, so it does not make much sense to assign them an intrinsic size. But it does make a lot of sense to have an intrinsic ratio, so resizing the image respects the proportions.
Created attachment 447700 [details] Patch
Comment on attachment 447700 [details] Patch r=me
Committed r287355 (245497@trunk): <https://commits.webkit.org/245497@trunk>
<rdar://problem/86810685>