Created attachment 262879 [details] [Image] Actual/Expected See the attached image and HTML reduction.
Created attachment 262880 [details] [HTML] Reduction
This regressed in http://trac.webkit.org/changeset/189567, so the current behaviour is probably the intended one. I wonder how many websites this change will break.
(In reply to comment #2) > This regressed in http://trac.webkit.org/changeset/189567, so the current > behaviour is probably the intended one. I wonder how many websites this > change will break. Firefox renders that test as WebKit ToT
Also what happens if you set min-width:0px; as suggested in the ChangeLog?
Chrome shows the same results as we do. Adding min-width:0 fixes the issue.
(In reply to comment #5) > Chrome shows the same results as we do. Adding min-width:0 fixes the issue. I think that the rendering in ToT is correct. I've checked Firefox and the input item is sized the same (looks like firefox has a bug as it draws a too wide outline for the filter-bar but the search item is sized as in WebKit).
Created attachment 279374 [details] Reduced test case I've removed the non essential stuff.
Created attachment 279375 [details] Web Engines Rendering These are the renderings of FF, Chrome and WebKit. All of them ToT. As you can see the only difference is the outline of the parent flex element. The search input item is not shrank at all in any of the engines. That's why I don't think that's a regression. If you want to achieve Safari 9 results then you definitely need to use min-width:0px as suggested.
Agreed. This is not a bug.