Menubar is overlaid by window buttons

REOPENED
Unassigned

Status

()

defect
P5
normal
REOPENED
6 years ago
2 years ago

People

(Reporter: mkaply, Unassigned)

Tracking

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(firefox47 unaffected, firefox48 wontfix, firefox49 wontfix, firefox50 wontfix, firefox51 affected)

Details

Attachments

(1 attachment)

If you resize the Firefox window smaller, the window buttons overlap the menu in the titlebar.

The menu should wrap or the window shouldn't be able to be sized that small.
I'm not sure we should increase the minimum width given the complaints we get already (bug 906168).

Wrapping the menu to another line would just be ugly. :-(
> Wrapping the menu to another line would just be ugly. :-(

Agreed, but that's the standard way to do it on Windows.
What happens in a current (non-Australis) release?
(In reply to Justin Dolske [:Dolske] from comment #3)
> What happens in a current (non-Australis) release?

The menu isn't in the title bar, so it's not an issue.
https://hg.mozilla.org/mozilla-central/rev/b732738b75f8
Assignee: nobody → smontagu
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 30 → ---
(that was bug 964281)
Assignee: smontagu → nobody
Duplicate of this bug: 1281778
Dup bug 1281778 shows 48-50 as affected and has this issue marked as a regression. Carrying over flags.
Flags: needinfo?(gijskruitbosch+bugs)
Too late for 49. Gijs, is this something you want the platform triage or relman to keep tracking? Or is it something for your backlog to assess?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #9)
> Too late for 49. Gijs, is this something you want the platform triage or
> relman to keep tracking? Or is it something for your backlog to assess?

Because this isn't a recent regression I don't think it needs relman tracking. There's a recent-ish thing on win10 where this is slightly worse because of how our titlebar buttons work there. I still don't think the severity of that additional issue warrants tracking (see bug 1281778 for more detail).

I set needinfo?me because I'm curious if there's a reasonably simple way to solve this, and I would like to look at that when I find some time, but I've been busy since I came back from PTO so I haven't found said time yet.
There are a couple of issues here:

- the win10 buttons are transparent and so the result is messier there than on previous versions of Windows
- the caption buttons can be different sizes depending on screen resolution etc.
- we currently let the toolbox and toolbars have min-width: 1px, and so the window can be resized such that the ends of the toolbars go off-screen. If we leave this in place, we'd likely need to wrap things manually. That is, we'd need to manually update the maximum allowed width of the menubar when the window resizes. We can't even just use variables and calc() to solve this because there could be other items on the toolbar.
- even removing the min-width off the toolbar and toolbox, I'm still seeing the window getting smaller than the toolbar. I'm not sure why.
- in theory, once the menubar has a defined width, it should be possible to make the items inside it wrap with new flex box and flex-wrap. In practice, I have not been able to find a way to make this work. At all.
- if that's true and not just my lack of ingenuity, there's no way to do this without using the age-old hack of a <description> element to make the kids wrap, maybe inside the menubar. That's likely to cause a11y issues and in any case is a markup rather than just styling change.

All of this means that it is very much non-trivial to fix this. Given that we've lived with this since ~forever, I don't think this needs to be prioritized.
Flags: needinfo?(gijskruitbosch+bugs)
Keywords: regression
Priority: -- → P5
Duplicate of this bug: 1435255
You need to log in before you can comment on or make changes to this bug.