After SVN rev 123770 (for Bug 92143) the Remote Web Inspector's buttons are using -webkit-flex: 0. This doesn't work so well on older versions of webkit, but oh well, I'll update. I update, and it computes out to flex-basis: 0px; flex-shrink: 1; flex-grow: 0;... That's odd. According to the spec ( http://www.w3.org/TR/css3-flexbox/ ) that would mean it gets 0px of width assigned (irrespective of the buttons' width properties), then doesn't grow (only shrinking if there's insufficient space, which is rarely a problem) Yet, in Chrome versions > 21, it lays out properly. That's decidedly odd. It's as though WebCore suddenly (between Chromes 21 and 22) started treating flex-basis: 0px the exact same as flex-basis: auto. I'm familiar with the CSS specs (I helped write BlackBerry's old rendering engine) but not with how WebCore implements them, so my attempts at code archaeology so far have failed. I don't know what change caused the renderer to fall from spec, but it does appear to be failing. Note: inspector.css' -webkit-flex: 0; is incorrect (wrt spec) and, upon resolution of this bug, will need to be changed.
Can you include a screen shot of the problem? I'm having a hard time understanding from the description. I think what you're saying is that a button with flex:0 should be given 0 space. In this case, that's not happening because of section 4.4. Implied Minimum Size of Flex Items: http://www.w3.org/TR/css3-flexbox/#min-size-auto The min-width of the button is auto, which resolves to min-content (i.e., the size of the button).
Created attachment 161735 [details] A screenshot of the issue, as requested
I can't find any min-width: auto declarations in inspector.css: http://trac.webkit.org/browser/trunk/Source/WebCore/inspector/front-end/inspector.css ohhh... the flex spec makes the new initial value of min-width auto as well. And if the version of the engine doesn't support min-width: auto (which is true for everything before SVN 122264) then there are problems. So, in the flex layout algorithm, the flex base size is still 0 (because of the definite size (bad form for using the ambiguously-defined unitless 0, though)) but its hypothetical main size is clamped to min-width. Geez, that's a roundabout way of just saying flex: initial; :D So it's not actually incorrect as I originally stated. I apologize. Can I change this bug to simply requesting the replacement of -webkit-flex: 0; with -webkit-flex: initial; since that's a notation that has higher levels of support?
Bug retitled. It would be equivalent to use -webkit-flex: initial or just omit -webkit-flex since it would produce the same results in this case.
Created attachment 161753 [details] Patch
Created attachment 161757 [details] Patch
Comment on attachment 161757 [details] Patch Attachment 161757 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/13715384
Comment on attachment 161757 [details] Patch Clearing flags on attachment: 161757 Committed r127352: <http://trac.webkit.org/changeset/127352>
All reviewed patches have been landed. Closing bug.