1604427 - Min/Max/Close browser options are not available for min width when "Menu bar" is on

Status: NEW

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Valentina Virlics [:vvalentina], Ecosystem QA]

[Affected Versions]:

• Firefox Nightly 73.0a1 (Build ID 20191216214733)
• Firefox Beta 72.0b6 (Build ID 20191212210843 )
• Firefox Release 71.0 (Build ID 20191202093317)

[Affected Platforms]:

• Windows

[Steps to reproduce]:

1. Open Firefox browser.
2. Right-click on toolbar and activate "Menu bar" option.
3. Change the width of the browser towards min.
4. Observe browser resize options.

[Expected results]:
Min/Max and Close options are available and actionable.

[Actual results]:
Min/Max and Close options are not available.

[Regression]:

• Last good revision: 9f9a9234959f114825f58beee0cffbab82d0bb29 (2018-11-05)
• First bad revision: 6e842238034cd847ede178b4e65ea07704e4ffe6 (2018-11-06)
  Pushlog:
  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f9a9234959f114825f58beee0cffbab82d0bb29&tochange=6e842238034cd847ede178b4e65ea07704e4ffe6

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Comment 2

[Pascal Chevrel:pascalc]

Regression in 65, the fix should ride the trains.

Comment 3

[:Gijs (he/him)]

This is fixable if we use new-style flexbox for the menubar, and allow the menu items to shrink and not grow (and give them a min-width, and overflow: -moz-hidden-unscrollable so the menubar disappears under the caption buttons). I don't think this is "properly" fixable in old-style flexbox because I don't think we can make the menubar box shrink but not grow, and mixing that with float or abspos to make the buttons stay on top seems like a headache. Dão, is this right or am I missing something?

However, using new-style flexbox means also switching the old-style moz-box-ordinal-group to new-flexbox order, and it conflicts with the search box and flexible space widgets (which use old-style flexbox). We could get around this by using different CSS in the menubar vs. everywhere else, but that feels like quite an involved / risky change for limited gain here. So I'm going to backlog this bug for now. Brian, looping you in because it ties into our wanting to switch away from old-style flex attributes, though I guess we're still a while away from making a full-on switch?

Comment 4

[:Gijs (he/him)]

The same problem can also happen in the tabstrip if you have a lot of pinned tabs.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to :Gijs (he/him) from comment #3)

This is fixable if we use new-style flexbox for the menubar, and allow the menu items to shrink and not grow (and give them a min-width, and overflow: -moz-hidden-unscrollable so the menubar disappears under the caption buttons). I don't think this is "properly" fixable in old-style flexbox because I don't think we can make the menubar box shrink but not grow, and mixing that with float or abspos to make the buttons stay on top seems like a headache. Dão, is this right or am I missing something?

However, using new-style flexbox means also switching the old-style moz-box-ordinal-group to new-flexbox order, and it conflicts with the search box and flexible space widgets (which use old-style flexbox). We could get around this by using different CSS in the menubar vs. everywhere else, but that feels like quite an involved / risky change for limited gain here. So I'm going to backlog this bug for now. Brian, looping you in because it ties into our wanting to switch away from old-style flex attributes, though I guess we're still a while away from making a full-on switch?

Thanks for the heads up. By the way, if we are using the actual [ordinal] property/attribute here we are planning to remove support for that to directly use el.MozBoxOrdinalGroup from JS or -moz-box-ordinal-group from CSS for the handful of existing consumers in Bug 1603830. It sounds like that shouldn't have any effect for this issue in particular but just wanted to give a heads up.

It might also be worth checking if running with 'flexbox emulation' (via the layout.css.emulate-moz-box-with-flex pref), perhaps with the other CSS changes you mention, fixes anything here. In that mode, we translate the old-style flex rules into new-style flex behind the scenes. We aren't ready to ship that yet due to perf work for CSS flexbox and some functionality issues (which are partly being addressed by the work in Bug 1603830, etc). But it might give some sense of how risky porting the rest of the UI to directly use new-style would be, or allow us to block a fix on that being ready (tracked in the meta Bug 1033225).

Comment 6

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi, I've updated the version's flags.

I reproduced this bug on latest firefox nightly 74.0a1 (2020-01-07) (64-bit) for Windows 10 pro.

Best,
Clara

Comment 7

[Dão Gottwald [:dao]]

(In reply to :Gijs (he/him) from comment #3)

This is fixable if we use new-style flexbox for the menubar, and allow the menu items to shrink and not grow (and give them a min-width, and overflow: -moz-hidden-unscrollable so the menubar disappears under the caption buttons). I don't think this is "properly" fixable in old-style flexbox because I don't think we can make the menubar box shrink but not grow, and mixing that with float or abspos to make the buttons stay on top seems like a headache. Dão, is this right or am I missing something?

Sounds about right. I see no easy way to fix this.

[...] but that feels like quite an involved / risky change for limited gain here. So I'm going to backlog this bug for now.

Agreed, this is enough of an edge case (shipped for a year before somebody noticed) that it doesn't need to be an immediate priority.

Comment 9

[:Gijs (he/him)]

We had a recent dupe filed and I looked again at my comment here:

(In reply to :Gijs (he/him) from comment #3)

This is fixable if we use new-style flexbox for the menubar, and allow the menu items to shrink and not grow (and give them a min-width, and overflow: -moz-hidden-unscrollable so the menubar disappears under the caption buttons). I don't think this is "properly" fixable in old-style flexbox because I don't think we can make the menubar box shrink but not grow, and mixing that with float or abspos to make the buttons stay on top seems like a headache. Dão, is this right or am I missing something?

However, using new-style flexbox means also switching the old-style moz-box-ordinal-group to new-flexbox order, and it conflicts with the search box and flexible space widgets (which use old-style flexbox). We could get around this by using different CSS in the menubar vs. everywhere else, but that feels like quite an involved / risky change for limited gain here. So I'm going to backlog this bug for now. Brian, looping you in because it ties into our wanting to switch away from old-style flex attributes, though I guess we're still a while away from making a full-on switch?

Emilio, am I right in thinking that with bug 1790616 fixed this should be more doable now?

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Yes. At some point I'd like to do a mass migration to modern flexbox. The plan would be mostly something like:

• Change the default value of -moz-box-layout to flex (this doesn't change any behavior, it just allows us to remove some code).
• Put the visibility: collapse handling into its own property (so that the -moz-box visibility: collapse behavior could work with regular display: flex). That's the only current behavior difference between -moz-box and flex (other than the properties we look at).

It seems to me at that point we could do an automatic (or at least mostly-automatic?) -moz-box-to-flex migration, which would simplify this quite a lot.