Closed
Bug 964821
Opened 11 years ago
Closed 3 years ago
Menubar is overlaid by window buttons
Categories
(Firefox :: General, defect, P5)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox47 | --- | unaffected |
firefox48 | --- | wontfix |
firefox49 | --- | wontfix |
firefox50 | --- | wontfix |
firefox51 | --- | affected |
People
(Reporter: mkaply, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
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.
Comment 1•11 years ago
|
||
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. :-(
Reporter | ||
Comment 2•11 years ago
|
||
> Wrapping the menu to another line would just be ugly. :-(
Agreed, but that's the standard way to do it on Windows.
Comment 3•11 years ago
|
||
What happens in a current (non-Australis) release?
Reporter | ||
Comment 4•11 years ago
|
||
(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.
Comment 5•11 years ago
|
||
Assignee: nobody → smontagu
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 30
Updated•11 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Firefox 30 → ---
Comment 8•8 years ago
|
||
Dup bug 1281778 shows 48-50 as affected and has this issue marked as a regression. Carrying over flags.
status-firefox47:
--- → unaffected
status-firefox48:
--- → wontfix
status-firefox49:
--- → affected
status-firefox50:
--- → affected
Keywords: regression
Updated•8 years ago
|
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?
Comment 10•8 years ago
|
||
(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.
Comment 11•8 years ago
|
||
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.
Reporter | ||
Comment 13•3 years ago
|
||
This isn't an issue anymore based on how we do the window controls now.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•