593457 - Make menubar a popup anchored to the menu button

Status: NEW

(Firefox :: Theme, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Right now, when you hit Alt when running with glass, the menubar pops open and causes the entire window, including all content etc. to reflow.  It's chunky and slow.  Instead, we have space to the right of the Firefox button -- would be cool if the menubar slid out/faded in/whatever in that space instead, thus not changing the dimensions of anything in the browser window.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: quick cut-and-paste in dom inspector

This actually seems easy to do -- with a bit of dom inspector cut and paste, I can do this as seen in this attachment...

Comment 2

[Dão Gottwald [:dao]]

This became unbearably slow when bug 130078 landed. I hoped bug 591435 would fix it, but it didn't.

Comment 3

[Dão Gottwald [:dao]]

Note that the proposed solution would look rather weird on XP and conflict with bug 572160.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Bug 572160 only affects when the window is maximized; we could do it then as well, just have the menubar squish tabs off to the right temporarily or something.  Not sure that it would look any more weird on XP than the Firefox button does :-)

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

The Firefox button isn't on by default on XP, of course, so I'm fine with some oddness in the case where someone's already opted to mess about with the defaults.

Not sure we want to shove the tabs off to a side when the window is maximized, but it's probably easier to do that than it is to have it pop down in one mode. Also, it's a temporary movement, not permanent.

Vlad: got that cut and paste?

Comment 6

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

- inspect a window
- control-F, find id "main-menubar"
- cut
- control-F, find id "appmenu-button-container"
- right-click appmenu-button-container, Paste > After
- click "main-menubar", go to CSS rules, select "#main-menubar", and change -moz-box-flex to 0

(not doing the last step has the menubar and the spacer after it evenly distributed along the top, with the menubar getting a lot more room.  you can't grab the menubar to drag the window since we paint around it, but that wouldn't be an issue if it wasn't permanently visible.)

Could probably make it fade in/out on focus this way too, but that's more dom inspector work than i'm willing to do.

Comment 7

[Dão Gottwald [:dao]]

We really need to fix whatever makes this painfully slow. The menu bar isn't the only case that would resize the content are. Maximizing a window with 75 tabs takes three to four seconds over here.

Comment 8

[Timothy Nikkel (:tnikkel)]

ResizeReflow's for hidden views should normally be suppressed, but they slip through the backdoor. When we get a paint for the widget we call nsViewManager::CallWillPaintOnObservers. This goes through all view managers and calls WillPaint on their observer, whether or not the root view of the VM is (effectively) hidden. We can cut that off right there, just need to make sure the delayed resize happens when the view becomes visible. PresShell::WillPaint bails right away if painting is suppressed. We should probably also bail if we are not active.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sounds good to me!

Comment 10

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #7)
> We really need to fix whatever makes this painfully slow. The menu bar isn't
> the only case that would resize the content are. Maximizing a window with 75
> tabs takes three to four seconds over here.

Sure, though that's independent from this bug.  This isn't intended as fix for the slowdown, but also as a usability fix -- having your *entire browser window* jerk downwards is not really a great experience, no matter how fast it happens.

Comment 11

[Dão Gottwald [:dao]]

Looks like we'll need a new bug, either for moving the menubar elsewhere or for the perf issue...

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'd suggest a new bug for the specific perf fix, since this one covers the menubar issue pretty well :)

Comment 13

[Timothy Nikkel (:tnikkel)]

I will put the perf fix in a new bug. Thanks for bringing the perf problem to my attention, I didn't know about it until I was cc'd here, so if there are other problems please let me know.

Comment 14

[Timothy Nikkel (:tnikkel)]

Filed bug 594267 for the perf issue.

Comment 16

[Asa Dotzler [:asa]]

Attachment: proposal for oldstyle menu bar to become a simple menu on Alt key

Because we've moved the tabs into the titlebar space on maximized windows, it doesn't seem like this is the best solution any more. It doesn't feel quite right to push the tabs over, or to add an entire new row for displaying the menubar when a user hits the alt key. Perhaps it makes more sense to just pop-up the menubar from the Firefox button like a regular menu when the user hits the Alt key. Photoshop mock attached.

Comment 17

[Dão Gottwald [:dao]]

Morphing based on comment 16.