Closed Bug 940669 Opened 11 years ago Closed 10 years ago

On Gnome, the menu bar not visible at all. No hint on how to access it.

Categories

(Firefox :: Menus, defect)

Product:
Firefox
Component:
Menus
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firefox 29

People

(Reporter: hub, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P2])

Attachments

(4 files, 2 obsolete files)

whole desktop screenshot
143.35 KB, image/png
Details
Screen Shot 2013-11-21 at 23.51.24 .png
731.79 KB, image/png
Details
add button menu to toggle toolbars in Australis' customize mode,
9.70 KB, patch
mconley
: review+
Details | Diff | Splinter Review
Screenshot from 2014-04-07 08:07:52.png
196.71 KB, image/png
Details 
On Gnome, the menu bar not visible at all. No hint on how to access it. Until one press "Alt".

I started with a new profile to test that.

See attached screenshot

This is a follow up on bug 940040 - but not the same problem.
Also the fact that even "customize" doesn't offer the option is mind boggling.
(In reply to Hubert Figuiere [:hub] from comment #1)
> Also the fact that even "customize" doesn't offer the option is mind
> boggling.

Or, you know, it was something explicitly requested by Linux desktop folks, and you can get it back by simply right clicking the navbar and clicking 'menu bar' in the context menu.

Also, this is probably just a dupe of bug 940228 but Linux window managers are insane so I can't actually be sure.
I use the default Gnome 3 window manager. Not some fancy stuff that 5 people in the world use. And no you don't use the Gnome shell application menu either.

But to put it that way, I'm OK if you just remove fix 940040 and then allow the add-on menu items to be accessible easily. *hint*: they are not.
And no it is not because the "Linux desktop folks" as you describe them asked for it that it is good. I'm a Linux desktop person too and completly disagree. There are also people who hate Gnome 3 because it change their habits. Etc.
Blocks: 896887
(In reply to Hubert Figuiere [:hub] from comment #4)
> And no it is not because the "Linux desktop folks" as you describe them
> asked for it that it is good. I'm a Linux desktop person too and completly
> disagree. There are also people who hate Gnome 3 because it change their
> habits. Etc.

(In reply to Hubert Figuiere [:hub] from comment #3)
> I use the default Gnome 3 window manager. Not some fancy stuff that 5 people
> in the world use. And no you don't use the Gnome shell application menu
> either.

I'm merely pointing out that the decision isn't "mind boggling" or in any way clear-cut, as far as I'm concerned, and I'm getting tired of people trying to prove that either way is best just by trying to shout the loudest. This applies to this decision just as much as various other decisions related to Australis.

It's *not* 100% clear whether keeping or removing the menu by default is the best. There are pros and cons. These pros and cons have different weight for different people. Making a decision which will impact everyone requires careful weighing of these by people who actually know this stuff, and ideally user testing (which we have done, although not specifically on Linux) so that we have actual data. We will never make all of our users happy at the same time - especially not Linux users, bless you all. But please, for the love of all that's holy, stop trying to pretend it's got to be your way or the highway and anyone who doesn't agree is a fool, whilst providing no arguments or reasons for your opinion.

</rant>

Someone on the UX team should weigh in on whether we want to reverse the decision made in bug 896887.
Flags: needinfo?(madhava)
Here is the thing. The effect of the "alt" key on the whole UI is mindboggling - be it in the context of show the menu bar or in the context of bug 940040. There is only ONE app on Linux that does that and it is Firefox with Australis. That's what I dislike the most. The rest I could eventually live with it.

Adding the option to "customize" would also be consistent with the rest - I didn't find a way to do it in there.

Also wiping out the legacy of add-on in one shot if pretty bad. I mean if we really want get rid of add-ons we should just get rid of them instead of breaking most of them saying "they will be updated". Experience show that it might not even happen. The Gnome design cabal has done the same and it lead if a very bad situation were some app features have been broken for 4 years. Firefox UX could learn from that too.

The rest was just initial confusion.
And FWIW, I just set ui.key.menuAccessKeyFocuses to false and it still does it.
(In reply to Hubert Figuiere [:hub] from comment #7)
> And FWIW, I just set ui.key.menuAccessKeyFocuses to false and it still does
> it.

The bug is that it needs a restart :-/
Also two more things:

F10 works to show the menu bar even with the above setting set to false. This WFM. This is how it works elsewhere in Gnome be it Gtk2 or Gtk3 apps, and solve the accessibility and platform consistency issue.

The add-on issue has been filed as bug 940683. This is why I'm not the one to shout the loudest. I actually properly file bugs.
(In reply to Hubert Figuiere [:hub] from comment #6)
> Here is the thing. The effect of the "alt" key on the whole UI is
> mindboggling - be it in the context of show the menu bar or in the context
> of bug 940040. There is only ONE app on Linux that does that and it is
> Firefox with Australis. That's what I dislike the most. The rest I could
> eventually live with it.

This is bug 940040, let's not discuss that here.

> Adding the option to "customize" would also be consistent with the rest - I
> didn't find a way to do it in there.

View > Toolbars > Customize...

It's always been there (also pre-australis).

> Also wiping out the legacy of add-on in one shot if pretty bad. I mean if we
> really want get rid of add-ons we should just get rid of them instead of
> breaking most of them saying "they will be updated".

I take an amount of personal offense at the suggestion that we "want to get rid of add-ons" that is difficult to convey without breaking bugzilla etiquette rules. I personally tested well over 100 of the most popular and featured add-ons on AMO with some of the changes we are making. It's extremely disingenuous to claim we're breaking anybody for the sake of it. Yes, some of our changes will break add-ons, but we've gone to pretty extreme lengths to limit the breakage. See bug 749804 wrt what I'm talking about.

If we're just talking about adding items to the main menu, we didn't break anything wrt them doing that - it's just that the menu is no longer visible by default on Linux. It was already invisible on Windows > XP. That is what this bug is about. It's a reasonable point to argue that may make some add-ons harder to discover, and we should take that into account when considering whether to revert this change. But please don't be quite as melodramatic as to suggest we're purposely "getting rid of add-ons".

All your other comments seem to pertain to bug 940040. I'm sure we'll fix that bug even if we keep the menubar toggled off by default. Shouting about it here will do nothing to help.
> > Adding the option to "customize" would also be consistent with the rest - I
> > didn't find a way to do it in there.
> 
> View > Toolbars > Customize...

With the menu bar not visible. So Australis is based on totally using that "menu button" and the new "customize" and yet to customize the visibility of a UI item one has to actually make that UI item visible first to make it visible?

There is something just wrong in that picture.



> If we're just talking about adding items to the main menu, we didn't break
> anything wrt them doing that - it's just that the menu is no longer visible
> by default on Linux. 

Bingo.

> It was already invisible on Windows > XP. That is what
> this bug is about. It's a reasonable point to argue that may make some
> add-ons harder to discover, and we should take that into account when
> considering whether to revert this change. But please don't be quite as
> melodramatic as to suggest we're purposely "getting rid of add-ons".

Not necessarily revert the change. Just make these things available with the new UX paradigm.
And no I don't have a solution to offer off the top of my head. Nor is all the attitude inviting to think about one.
I think the problem is not that the menu is hidden by Default, I am a linux and Gnome Shell user and I use Firefox with the top menu hidden by default since Firefox 4, the problem is more that currently turning this menu on or off is doable via the Firefox button and is no longer doable via the new preferences button in Australis. I believe this should be doable via the customize mode in Australis. 

I think that the discoverability of the top menu is also going to be a problem for platforms that don't use a unified menu, that means that Windows is impacted too. There are items that are less essentials in the menu but still occasionnally useful for end users that I don't know how users will access to in Australis (printing settings for example, sync configuration, all the add-ons that are accessible via the tools menu such as the Nightly Testers tools).
(In reply to Pascal Chevrel:pascalc from comment #13)
> I think the problem is not that the menu is hidden by Default, I am a linux
> and Gnome Shell user and I use Firefox with the top menu hidden by default
> since Firefox 4, the problem is more that currently turning this menu on or
> off is doable via the Firefox button and is no longer doable via the new
> preferences button in Australis. I believe this should be doable via the
> customize mode in Australis. 

This makes sense, and I have an idea on how to fix this. I'll try and come up with a patch later today.

> I think that the discoverability of the top menu is also going to be a
> problem for platforms that don't use a unified menu, that means that Windows
> is impacted too.

Nothing changed on Windows. Still hidden by default on Vista, Win7 and later, still visible by default on XP. Note that I would actually have expected add-ons to deal with this kind of situation because of Windows > XP. In that sense, this is nothing new - it's just new on Linux.

> There are items that are less essentials in the menu but
> still occasionnally useful for end users that I don't know how users will
> access to in Australis
> (printing settings for example,

The print button on non-mac invokes the print preview command, from which printing settings are accessible. On OS X there's a unified menubar (and the print command shows a dialog with the settings anyway).

> sync configuration,

Preferences button > Sync tab

> all the add-ons that are accessible via the tools menu such as the Nightly
> Testers tools).

I don't know (m)any add-ons that only provide tools menu items and no toolbar buttons or so on. This point was brought up earlier, and I agree that this is a problem with the current approach. I am not sure how big the problem is. I don't think it's very fixable from our side though - in order to have a toolbar button, we really need to have some kind of artwork for it. On the plus side, I would think that Linux users who install such add-ons will probably figure out they can still get to the toolbar using alt/f10, or using the context menu on a toolbar, or using whatever solution we come up with within Customize Mode, if any.
(In reply to :Gijs Kruitbosch from comment #14)
> (In reply to Pascal Chevrel:pascalc from comment #13) 
> > I think that the discoverability of the top menu is also going to be a
> > problem for platforms that don't use a unified menu, that means that Windows
> > is impacted too.
> 
> Nothing changed on Windows. Still hidden by default on Vista, Win7 and
> later, still visible by default on XP. Note that I would actually have
> expected add-ons to deal with this kind of situation because of Windows >
> XP. In that sense, this is nothing new - it's just new on Linux.
> 

It did change in Windows since there was a menu item that people could click via the Firefox button so as to activate/deactivate the menu bar and that possibility was removed in Australis for them.
(In reply to :Gijs Kruitbosch from comment #14)
> (In reply to Pascal Chevrel:pascalc from comment #13)
> > all the add-ons that are accessible via the tools menu such as the Nightly
> > Testers tools).
> 
> I don't know (m)any add-ons that only provide tools menu items and no
> toolbar buttons or so on. This point was brought up earlier, and I agree
> that this is a problem with the current approach. I am not sure how big the
> problem is. I don't think it's very fixable from our side though 

I have 2 addons that have this problem, Nightly Testers Tools and Mass Password Reset. 
Interestingly, they are both maintained by Mozilla employees :D

> to have a toolbar button, we really need to have some kind of artwork for
> it. On the plus side, I would think that Linux users who install such
> add-ons will probably figure out they can still get to the toolbar using
> alt/f10, or using the context menu on a toolbar, or using whatever solution
> we come up with within Customize Mode, if any.

The addons mentionned are not Linux specific, I think it would be good to expose a toggle for toolbars in the customize page, regardless of the OS. I know Windows users that insist on having the menu bar activated because they are used to work with a menu bar in all of their apps.
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Hubert Figuiere [:hub] from comment #11)
> > > Adding the option to "customize" [...]
> > 
> > View > Toolbars > Customize...
> 
> With the menu bar not visible. So Australis is based on totally using that
> "menu button" and the new "customize" and yet to customize the visibility of
> a UI item one has to actually make that UI item visible first

No. Customize is also available as one of the top-level options in the Australis Menu (the button with 3 horizontal lines in upper-right), which is not hidden.
> No. Customize is also available as one of the top-level options in the
> Australis Menu (the button with 3 horizontal lines in upper-right), which is
> not hidden.

Not what I said. What I said is that I can't configure the menu bar visibility in customize. That basically to configure the menu bar visibility I have ti show the menu bar first. (ok there is also right click). Actually having a "show menu bar" within the customize UI would solve most of the issue, the Australis way™
The patch is not very big. I'll add a screenshot in a bit, which unfortunately is on mac so it only shows the bookmarks toolbar, but I hope you all have enough imagination to figure out what it'd work like on Linux.
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Madhava, how would you feel about adding a button here that has a dropdown menu to toggle the toolbars?

For consistency, we could also make "Restore Defaults" reset the toolbar visibility back to their defaults (menu/bookmark bar would be hidden).

This would be consistent with the earlier decision to fix the context menus for the toolbars to allow toggling them while in customize mode (rather than disabling the menus) and would provide more discoverability than the context menu.

(Please disregard the grey styling, that's because of bug 936815)
Attachment #8336426 - Flags: ui-review?(madhava)
Flags: needinfo?(madhava)
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs Kruitbosch from comment #20)
> Madhava, how would you feel about adding a button here that has a dropdown
> menu to toggle the toolbars?

(drive-by observation: In the screenshot, the only listed toolbar is "Bookmark Toolbar" -- but the key toolbar-of-interest in this bug was the Menu Bar. Presumably the Menu Bar will end up being included in that menu too, right?)
(In reply to Daniel Holbert [:dholbert] from comment #21)
> (In reply to :Gijs Kruitbosch from comment #20)
> > Madhava, how would you feel about adding a button here that has a dropdown
> > menu to toggle the toolbars?
> 
> (drive-by observation: In the screenshot, the only listed toolbar is
> "Bookmark Toolbar" -- but the key toolbar-of-interest in this bug was the
> Menu Bar. Presumably the Menu Bar will end up being included in that menu
> too, right?)

(In reply to :Gijs Kruitbosch from comment #19)
> Created attachment 8336414 [details] [diff] [review]
> add menu to toggle toolbars in customize mode, ui-
> 
> The patch is not very big. I'll add a screenshot in a bit, which
> unfortunately is on mac so it only shows the bookmarks toolbar, but I hope
> you all have enough imagination to figure out what it'd work like on Linux.

(By which I meant, yes, it's missing the menu bar on OS X because we have a global menubar there. It'd be there on Linux - doesn't take any extra code either because the menu is generated dynamically.)
Whiteboard: [Australis:P2]
So, the piece of the menu puzzle I know is: When chrisccoulson was packaging Firefox for Ubuntu, he bundled an add-on that moved the menubar in the unified menubar, so that it would be visible.

Perhaps we can always show the menu in the unified menu, if there is one?

Hub: Would that solve your problem, or am I mis-reading your screenshot?
(In reply to Blake Winton (:bwinton) from comment #23)
> So, the piece of the menu puzzle I know is: When chrisccoulson was packaging
> Firefox for Ubuntu, he bundled an add-on that moved the menubar in the
> unified menubar, so that it would be visible.
> 
> Perhaps we can always show the menu in the unified menu, if there is one?
> 
> Hub: Would that solve your problem, or am I mis-reading your screenshot?

I think Hub's screenshot is Gnome 3 rather than Ubuntu's Unity, so there isn't a unified menubar. I think?
Flags: needinfo?(hub)
In Gnome, there is an application menu which is not the "unified" menu. See https://wiki.gnome.org/GnomeGoals/PortToGMenu

Notice how there is a line in the Todo for Firefox and Thunderbird.

It requires GMenu which is in a recent glib. I don't think it requires Gtk3, but if it does it clearly is a no go.
Flags: needinfo?(hub)
(In reply to :Gijs Kruitbosch from comment #20)
> Created attachment 8336426 [details]
> Screen Shot 2013-11-21 at 23.51.24 .png
> 
> Madhava, how would you feel about adding a button here that has a dropdown
> menu to toggle the toolbars?
> 
> For consistency, we could also make "Restore Defaults" reset the toolbar
> visibility back to their defaults (menu/bookmark bar would be hidden).
> 
> This would be consistent with the earlier decision to fix the context menus
> for the toolbars to allow toggling them while in customize mode (rather than
> disabling the menus) and would provide more discoverability than the context
> menu.
> 
> (Please disregard the grey styling, that's because of bug 936815)

Two check-boxes would be better to improve visibility (one in OSX case).
(In reply to Guillaume C. [:ge3k0s] from comment #26)
> (In reply to :Gijs Kruitbosch from comment #20)
> > Created attachment 8336426 [details]
> > Screen Shot 2013-11-21 at 23.51.24 .png
> > 
> > Madhava, how would you feel about adding a button here that has a dropdown
> > menu to toggle the toolbars?
> > 
> > For consistency, we could also make "Restore Defaults" reset the toolbar
> > visibility back to their defaults (menu/bookmark bar would be hidden).
> > 
> > This would be consistent with the earlier decision to fix the context menus
> > for the toolbars to allow toggling them while in customize mode (rather than
> > disabling the menus) and would provide more discoverability than the context
> > menu.
> > 
> > (Please disregard the grey styling, that's because of bug 936815)
> 
> Two check-boxes would be better to improve visibility (one in OSX case).

There would be more checkboxes if there are third-party toolbars, and the height/width of all of them would be (very) variable, which leads to layout problems. I don't think visibility is an issue beyond the bad styling of (both) those buttons, which is a completely separate issues.
I like the direction of Gijs with the single control on the customization screen.
It makes sense to have a modified version of this on every platform, as it provides a good control mechanism for various toolbars (especially addons).
I think the button should also have an arrow-down-icon, to show that it will open a menu instead of triggering an action right away.

Zhenshuo, you have the best overview of the customization experience. Do you think this would be the way to go?
Flags: needinfo?(zfang)
This spec could be used for the dropdown : https://bug738796.bugzilla.mozilla.org/attachment.cgi?id=8342671
(In reply to Philipp Sackl [:phlsa] from comment #28)
> I like the direction of Gijs with the single control on the customization
> screen.
> It makes sense to have a modified version of this on every platform, as it
> provides a good control mechanism for various toolbars (especially addons).
> I think the button should also have an arrow-down-icon, to show that it will
> open a menu instead of triggering an action right away.
> 
> Zhenshuo, you have the best overview of the customization experience. Do you
> think this would be the way to go?

Talked to Gijs and Philipp about this, the next steps we came up with are:
• For Windows & Linux, use the control Gijs has in the mockup with a dropdown indication, to show a list of toolbars that user can toggle
• For Mac, if Bookmarks toolbar is the only thing in the dropdown, since user can already toggle it using the context menu in customization mode, we can hide the dropdown control
• And for Australis v2, we need to think about a better control or location to make adding/removing toolbars more intuitive
Flags: needinfo?(zfang)
Comment on attachment 8336426 [details]
Screen Shot 2013-11-21 at 23.51.24 .png

Clearing ui-review per fang's comment.
Attachment #8336426 - Flags: ui-review?(madhava)
This addresses Zhenshuo's concerns. Mike, what do you think?
Attachment #8360360 - Flags: review?(mconley)
Attachment #8336414 - Attachment is obsolete: true
Comment on attachment 8360360 [details] [diff] [review]
add button menu to toggle toolbars in Australis' customize mode,

Review of attachment 8360360 [details] [diff] [review]:
-----------------------------------------------------------------

Just a few concerns here...

::: browser/base/content/browser.js
@@ +4229,5 @@
>    }
>  }
>  
> +function getTogglableToolbars() {
> +  let toolbarNodes = Array.slice(gNavToolbox.childNodes);

Could this not be simplified to:

document.querySelectorAll("toolbar[toolbarname]");

?

::: browser/components/customizableui/src/CustomizeMode.jsm
@@ +117,5 @@
> +      let toolbarVisibilityBtn = document.getElementById(kToolbarVisibilityBtn);
> +      let togglableToolbars = window.getTogglableToolbars();
> +      let bookmarksToolbar = document.getElementById("PersonalToolbar");
> +      if (togglableToolbars.length == 0 ||
> +          (togglableToolbars.length == 1 && togglableToolbars[0] == bookmarksToolbar)) {

Wasn't this constraint only supposed to apply to OS X?

@@ +118,5 @@
> +      let togglableToolbars = window.getTogglableToolbars();
> +      let bookmarksToolbar = document.getElementById("PersonalToolbar");
> +      if (togglableToolbars.length == 0 ||
> +          (togglableToolbars.length == 1 && togglableToolbars[0] == bookmarksToolbar)) {
> +        toolbarVisibilityBtn.setAttribute("onetoolbar", "true");

What does onetoolbar do? A search through this patch, and a dxr search show no results for this attribute.

Is a file missing, or did I miss something?
Attachment #8360360 - Flags: review?(mconley) → review-
(In reply to Mike Conley (:mconley) from comment #33)
> > +  let toolbarNodes = Array.slice(gNavToolbox.childNodes);
> 
> Could this not be simplified to:
> 
> document.querySelectorAll("toolbar[toolbarname]");
> 
> ?

No, this would be a behavior change, as it would catch toolbars that didn't tie themselves to gNavToolbox.
So I removed the relevant CSS but forgot to switch the attribute to hidden... fixed now. Dao answered your other question, and we discussed the OSX-only concern (basically, this was about having only the bookmarks toolbar in there, which could be toggled differently, so that's the check I built - in practice, on Windows/Linux there'll be the menubar in there anyway, so they won't hit that condition).
Attachment #8360421 - Flags: review?(mconley)
Attachment #8360360 - Attachment is obsolete: true
Comment on attachment 8360421 [details] [diff] [review]
add button menu to toggle toolbars in Australis' customize mode,

Review of attachment 8360421 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the string updated. Thanks Gijs!

::: browser/locales/en-US/chrome/browser/browser.dtd
@@ +677,5 @@
>  <!ENTITY customizeMode.tabTitle "Customize &brandShortName;">
>  <!ENTITY customizeMode.menuAndToolbars.label "Menu and toolbars">
>  <!ENTITY customizeMode.menuAndToolbars.header "More Tools to Add to the Menu and Toolbar">
>  <!ENTITY customizeMode.restoreDefaults "Restore Defaults">
> +<!ENTITY customizeMode.toolbars "Toggle Toolbars">

Talking to phlsa, we feel "Toggle" might be too technical - Show / Hide might be better here.

So, "Show / Hide Toolbars" for now.

The positioning is fine for now, but we might want to iterate on it as we use it. Especially considering that I'm pretty certain we're going to be adding a similar toggle affordance for tabs in titlebar.
Attachment #8360421 - Flags: review?(mconley) → review+
remote:   https://hg.mozilla.org/integration/fx-team/rev/f59e8e882e26
Whiteboard: [Australis:P2] → [Australis:P2][fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/f59e8e882e26
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P2][fixed-in-fx-team] → [Australis:P2]
Target Milestone: --- → Firefox 29
Hubert, can you please verify that this is fixed for you in Firefox 29?
Flags: needinfo?(hub)
Yes we can customize whether to show the menu bar or not in the customize.

One little detail in that implementation it that it would be one step further by showing the menubar in the customization instead of just its space. I can file a new bug for that if needed.
Status: RESOLVED → VERIFIED
Flags: needinfo?(hub)
(In reply to Hubert Figuiere [:hub] from comment #40)
> One little detail in that implementation it that it would be one step
> further by showing the menubar in the customization instead of just its
> space. I can file a new bug for that if needed.

I don't understand what you mean. Can you clarify?
Flags: needinfo?(hub)
I have outlined in red the empty area that appear when making the menu bar visible. It should say something. At least "menu bar". Ideally it should show the actual menu bar. Either or is better than an empty area.
Flags: needinfo?(hub)
(In reply to Hubert Figuiere [:hub] from comment #42)
> Created attachment 8402614 [details]
> Screenshot from 2014-04-07 08:07:52.png
> 
> I have outlined in red the empty area that appear when making the menu bar
> visible. It should say something. At least "menu bar". Ideally it should
> show the actual menu bar. Either or is better than an empty area.

It shows the actual menubar, but the disabled text colors and the window background colors are both gray, so the text is very hard to make out. Please file a new bug. It'd be helpful if you could check what's causing these text/background colors and if it's something we can fix - if we're using (GTK) theme colors and the theme's colors are dumb, then...
I'll file a new bug. Indeed I completely missed them.

This is the standard theme used in Fedora 20 with Gnome 3.
Filed bug 992980
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: