Hypothetically the site here could work around this problem (and get a better rendering for Firefox/Safari users, with no change for Chrome users I think) by switching this declaration:
```css
.ui-autocomplete .ui-menu-item .definition {
flex: 0 0 400px;
```
to instead be:
```
.ui-autocomplete .ui-menu-item .definition {
flex: 0 0 auto;
width: 400px;
```
That ends up meaning the same thing for the flexbox algorithm, but with `width`, it means the child also gets to contribute a larger size earlier in layout as well, when the flex container is being intrinsically sized (following spec text in earlier versions of the flexbox spec, just using the straightforward intrinsic width contribution of the child).
Bug 1996140 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Hypothetically the site here could work around this problem (and get a better rendering for Firefox/Safari users, with no change for Chrome users I think) by switching this declaration:
```css
.ui-autocomplete .ui-menu-item .definition {
flex: 0 0 400px;
```
to instead be:
```css
.ui-autocomplete .ui-menu-item .definition {
flex: 0 0 auto;
width: 400px;
```
That ends up meaning the same thing for the flexbox algorithm, but with `width`, it means the child also gets to contribute a larger size earlier in layout as well, when the flex container is being intrinsically sized (following spec text in earlier versions of the flexbox spec, just using the straightforward intrinsic width contribution of the child).