Menu accelerators in Firefox don't follow the GNOME policy.

[Tomasz Chrzczonowicz]

Binary package hint: firefox

The current GNOME default is that menu accelerators are hidden, and shown when you press the ALT key.

Firefox doesn't observe this policy and have their menu accelerators displayed all the time.

Also, pressing ALT alone in GNOME and Firefox doesn't invoke any menu command.

This inconsistent behavior is a usability issue and also makes Ubuntu desktop look unprofessional.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Wed Jun 23 21:37:05 2010
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
ProcEnviron:
 PATH=(custom, user)
 LANG=pl_PL.utf8
 SHELL=/bin/bash
SourcePackage: firefox

[Shuang (shuang)]

Who should own this?

[Elig (elig)]

That's the easy part. ;)

[Mikepinkerton (mikepinkerton)]

accepting, m20.

[Matthew Paul Thomas (mpt)]

If I could cast negative votes, I would do so for this bug. Hiding keyboard
accelerators like this may prevent the user from ever realizing that menus can
be used from the keyboard, and thus may permanently slow them down.

In other words, Windows 2000 has got it wrong enough, and the difference in
appearance is minor enough, for it to be a good idea for Mozilla to be
deliberately inconsistent with the OS in this case. (In my opinion.)

[Trudelle (trudelle)]

Mass move of all M20 bugs to M30.

[Trudelle (trudelle)]

Mass moving M20 bugs to M30

[Dean-tessman (dean-tessman)]

Matt, I agree with you that not showing the accelerators is just dumb. There's
so many reasons for this. But it's also the way that the OS behaves. There are
people that don't like the single menu bar in MacOS, but we put it there for
platform parity. So someone has to make a call about doing the right thing or
doing the PP thing. And this is a setting that can be enabled/disabled in the
Display control panel, so it's not like it's being unconditionally forced on the
user.

If we're going to perform like the rest of the Win2000 menus, I can whip up some
code that checks this setting. Then, if someone points me to where the
underlines are drawn, I'll finish the job.

[Timeless-bemail (timeless-bemail)]

Warning, Windows 2000 is customizable. Display Properties, Effects Tab, Last
item:
Hide keyboard navigation indicators until I use the Alt key
the fun thing is that on this panel for some reason only two of the check boxes
are enabled and that isn't one of them (my box is very confused).

If you need me to track down the system setting in 2000 that determines this I
probably can. [My checkbox is unchecked and disabled, the system is behaving
like windows98]

[Timeless-bemail (timeless-bemail)]

oops i didn't mean to do that.

[Dean-tessman (dean-tessman)]

Yep, I know that it's a user-defined setting. That's why it would have to be
read in at various points during runtime.

[Dean-tessman (dean-tessman)]

Finally! After an hour or so of searching various sources, including the lovely
MSDN site, I something (anything) on how to retrieve this setting. Oddly
enough, it's in the form of a message and not a function or registry setting.
But there must be an underlying registry setting somewhere.

The message is WM_QUERYUISTATE although I'm not sure what window you'd send that
message to. When you think about it, you could probably send it to the
top-level Mozilla window, because it would inherit the default Windows settings
and would never change that setting.

More at...
http://msdn.microsoft.com/library/psdk/winui/keybacel_56qt.htm
http://msdn.microsoft.com/library/psdk/winui/keybacel_946d.htm

(It's good to see that Microsoft has absolutely no naming conventions anymore,
and that their names are distinct and concise.)

Another question about this setting, for someone with W2K to answer. Does this
apply only to menus or also to accelerators on buttons, fields, etc?

[Trudelle (trudelle)]

Mass-moving all M20-M30 XPToolkit bugs to Future

[Bugzilla-iwaruna (bugzilla-iwaruna)]

*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.

[Timeless-bemail (timeless-bemail)]

yes Menus and Buttons.
yes Labels.
what's a field? I think the answer is if it's being underlined then this pref
affects it.

[Dean-tessman (dean-tessman)]

Ugh. Any chance all of the accelerator key drawing is handled in one place?

[Timeless-bemail (timeless-bemail)]

Ben says hyatt or evaughan.
Hyatt?

[Dean-tessman (dean-tessman)]

Found it when looking for something else...

SystemParametersInfo(SPI_GETKEYBOARDCUES, ...)

See:
http://msdn.microsoft.com/library/psdk/sysmgmt/sysinfo_4p67.htm
http://msdn.microsoft.com/library/psdk/msaa/access_186q.htm

Don't know what I was thinking before.

[Bugzilla-blakeross (bugzilla-blakeross)]

I think I have this working. Stealing from mr. unresponsive module owner.

[Bugzilla-blakeross (bugzilla-blakeross)]

Nothing like deleting your tree and forgetting to save a patch.

[Matthew Paul Thomas (mpt)]

This isn't menu-specific, -->Toolkit/Widgets.

For what it's worth, I've completely changed my mind about what I said in my
2000-02-10 comment.

[Bugzilla-blakeross (bugzilla-blakeross)]

reassigning to default owner.

[James Ross (twpol)]

Just to confirm comment #14 - every keyboard accelerator is hidden by the
setting, but only until the user uses one of the keyboard navigation keys (these
include Tab and Alt) and the menu's show the underlines independantly from
buttons/labels etc.

E.g. After one Alt, then menu's show the underlines, and another Alt and they're
gone again (labels/buttons do not change at all for Alt).

Also (to add to the confusion) focus boxes (the dotty ones) also don't appear
with this option on - until you press Tab - and they don't disappear later.
However, they seem to be either program, or top-level window, independant.

There is one other thing: when I initially start Moz, I get underlines and the
access keys work - but after one reboot (with QuickLaunch on) - they are gone,
and the access keys no longer work. This is probably should not go under this
bug, but I really can't find a better place for it.

[Dean-tessman (dean-tessman)]

*** Bug 170029 has been marked as a duplicate of this bug. ***

[Nnbugzilla (nnbugzilla)]

To clarify (since I had to deal with this issue for my employer's apps), the
underlines for access keys are activated by the ALT key, as are focus rects.
However, focus rects alone can be activated by the use of the TAB key or other
dialog navigation key. Also note that Win2K itself does some of this wrong.
For example, you pretty much can't get tray app menus to show the underlines
correctly, because hitting ALT normally gets rid of the menu. Ugh.

[Timeless-bemail (timeless-bemail)]

re comment 24, you can get the tray menus to show underlines [w2k and beyond].
ctrl-escape, escape, tab (quicklaunch), tab (applist), tab (system tray), arrows
(select the thing you want), context key (get menu including access keys
underlined).

Note that the number of tabs to get from the start button to the system tray
will be at least two, but can vary by taskbar depending on what toolbars are
present, i just happen to have the default config.

[swalker (sdwalker)]

*** Bug 202518 has been marked as a duplicate of this bug. ***

[Muellkontrolle (muellkontrolle)]

@owner: Same on Windows XP

[Prognathous (prognathous)]

This bug has the potential to also affect other operating systems with mnemonics
support (e.g. Linux, BeOS etc...). In these cases, there should be a way to
disable mnemonics completely, even if they are, by default, used on these OSes.

Why would users want to hide mnemonics in such cases? many jsut find
parenthesised English mnemonics to be ugly-looking when spattered over l10n
interfaces. On the other hand, for those who need the accessibility this is a must.

I suggest to make this a pref or a hidden pref:

[x] Follow the OS handling of mnemonics
[ ] Always hide mnemonics
[ ] Always show mnemonics

I'm not sure about the last one, but personally I would like to have this when
using MacOS. For some "switchers" this could actually be regarded as a feature.

Prog.

[Prognathous (prognathous)]

Here's a screenshot of Mozilla (Hebrew UI) that shows why some users would
prefer to hide parenthesised mnemonics:

http://bugzilla.mozilla.org/attachment.cgi?id=135919&action=view

Prog.

[Tsahi-75 (tsahi-75)]

accesskeys look like that in hebrew mozilla because of bug 162081.

[Prognathous (prognathous)]

This isn't just about Hebrew. Using parenthesis is the only feasible way to
properly implement mnemonics in many asian languages (e.g. Chinese). Yet for
those who don't use/need it, it's nothing but an eyesore.

Prog.

[Tsahi-75 (tsahi-75)]

how does Win2k, or any other Win32, or other OSs, deal with it in those languages?

[Prognathous (prognathous)]

Tsahi, in Chinese Windows parenthesis is used, similar to Hebrew Mozilla. At
least that's what I found last month, in a visit to Beijing.

Prog.

[Mano-mozilla (mano-mozilla)]

*** Bug 266733 has been marked as a duplicate of this bug. ***

[Jruderman (jruderman)]

*** Bug 285745 has been marked as a duplicate of this bug. ***

[Random4444+bugzilla (random4444+bugzilla)]

(In reply to comment #17)
Links from comment 17 were no longer valid, but I did find this explanation for managing state of accelerators:
http://blogs.msdn.com/oldnewthing/archive/2005/05/03/414317.aspx

This meshes with comment 11, that the message does get passed up to the top window.

Off to look for where these messages would even go...

[Random4444+bugzilla (random4444+bugzilla)]

Additional info:
http://msdn.microsoft.com/en-us/library/ms695607(VS.85).aspx

So we need to pay attention to SPI_GETMENUUNDERLINES, updating whenever we receive WM_SETTINGCHANGE. We only have to check for entry-method if this is off, otherwise we always draw accelerators.

[Ehsan-mozilla (ehsan-mozilla)]

I gave this a shot, but it seems like either the description in <http://blogs.msdn.com/oldnewthing/archive/2005/05/03/414317.aspx> is flawed, or I'm missing somethign serious. I sent WM_CHANGEUISTATE, but never received a WM_UPDATEUISTATE notification. Calling WM_QUERYUISTATE half works: it detects if you press Alt for the first time, and can draw the underlines accordingly, but it wouldn't detect the next Alt press, which should clear the underlines from menus, for example. And detecting if a window has been opened via keyboard doesn't function correctly as well...

Does anyone know of better docs as to what should exactly happen to receive EM_UPDATEUISTATE?

[Stream (stream)]

Here is the Keyboard Accelerator Reference
http://msdn.microsoft.com/en-us/library/ms674704(VS.85).aspx

here is the WM_QUERYUISTATE Message
http://msdn.microsoft.com/en-us/library/ms646355(VS.85).aspx

I cant find anything about EM_UPDATEUISTATE

[Stream (stream)]

and WM_UPDATEUISTATE Message
http://msdn.microsoft.com/en-us/library/ms646361(VS.85).aspx

[Timeless-bemail (timeless-bemail)]

f10 should act like alt, shift-f10 should act like the context-menu key, all of these should enable underlines.

if i'm in a dialog, pressing alt should turn on underlines for the dialog (e.g. the font dialog in wordpad).

there's more logic for tabbed dialogs (the options dialog in wordpad). ctrl-tab should turn them on. it's possible to turn them off.

tab in a dialog doesn't seem to turn underlines on, but if you tab to the dialog tab and use arrows to select another, it should turn them on.

it's possible to turn off underlines with some clicks, but it isn't just one, it seems to be a combination of clicks to the content area of a tab plus clicking perhaps at least to two tabs. -- i'm having a lot of trouble making them go away.

note that alt tabbing to a dialog should result in the underlines being active in the dialog.

lastly, a dialog like find (wordpad) maintains its state independently of the app window, which means i can open find using the toolbar button, then i can task switch into the dialog and in some cases i'll have underlines enabled for the dialog, but it won't influence the main window (and of course if the dialog is open and i focus the content area and press alt, then the dialog doesn't grow underlines, only the menubar).

[Faaborg (faaborg)]

P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.

[Faaborg (faaborg)]

(switching to whiteboard for polish-relative priorities)

[Beltzner (beltzner)]

Disagree, as this requires a specific setting so I don't believe that it's a frequent user issue, changing to P2 as per definitions (note: please only modify these polish-* priorities if you're a member of the Firefox UX group)

[Dao (dao)]

(In reply to comment #65)
> as this requires a specific setting

The default setting is to hide the underlining, I think.

[Faaborg (faaborg)]

Yeah the existence of the setting to turn it back on is kind of peripheral to the issue, by default we underline a letter in each menu item when we shouldn't, which introduces a good amount of visual noise to the main window. This bug might end up getting invalidated by a removal of the menu bar though.

[Enn (enndeakin)]

(In reply to comment #67)
> This bug might end up getting invalidated by a removal of the menu bar though.

It would still be a valid bug for the underlines in all other parts of the UI though.

[Dao (dao)]

That, and it would still be valid for other XUL apps with a menu bar.

[Faaborg (faaborg)]

yep, both good points. If bug 418521 gets resolved I think this bug is a decent contender for the P0.

[Enn (enndeakin)]

Ehsan, are you still working on this? Is the handling of the system setting working OK? It would be good to take at least that part and use it with bug 418521.

[Ehsan-mozilla (ehsan-mozilla)]

(In reply to comment #71)
> Ehsan, are you still working on this? Is the handling of the system setting
> working OK? It would be good to take at least that part and use it with bug
> 418521.

No, I haven't touched this for several months. But the part about detecting the system setting is working OK based on my tests, so I think you can strip that part and use it in bug 418521.

[Ehsan-mozilla (ehsan-mozilla)]

Updating to reality: I won't have the time to work on this for the foreseeable future!

[Dao (dao)]

See also http://blogs.fedoraproject.org/wp/mclasen/2010/03/24/mnemonics/ for GTK.

[Tomasz Chrzczonowicz (tch)]

Binary package hint: firefox

The current GNOME default is that menu accelerators are hidden, and shown when you press the ALT key.

Firefox and OpenOffice.org don't observe this policy and have their menu accelerators displayed all the time.

Also, pressing ALT alone in GNOME and Firefox doesn't invoke any menu command, while in OpenOffice.org, it automatically opens the File menu.

This inconsistent behavior is an usability issue and also makes Ubuntu desktop look unprofessional.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: firefox 3.6.3+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.36-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Wed Jun 23 21:37:05 2010
EcryptfsInUse: Yes
FirefoxPackages:
 firefox 3.6.3+nobinonly-0ubuntu4
 firefox-gnome-support 3.6.3+nobinonly-0ubuntu4
 firefox-branding 3.6.3+nobinonly-0ubuntu4
 abroswer N/A
 abrowser-branding N/A
ProcEnviron:
 PATH=(custom, user)
 LANG=pl_PL.utf8
 SHELL=/bin/bash
SourcePackage: firefox

[Chris Cheney (ccheney)]

Well one obvious reason would be that neither of them are Gnome apps, they are both cross platform apps that use their own toolkit. It should be possible to modify them to work but it would probably not be trivial. And in the Firefox case you also have to get approval from upstream for any change made. :-\

[Robert Roth (evfool)]

The OpenOffice issue is also tracked at bug #123500.

[Chris Wilson (notgary-deactivatedaccount)]

It's not out of the ordinary for Ubuntu to maintain a few patches the fix problems that upstream doesn't want to fix. Hiding the menu accelerators is what most of Ubuntu's default applications do, so it's not unreasonable for the user to expect everything in Ubuntu to do it.

[Chris Wilson (notgary-deactivatedaccount)]

IT is generally a good idea to file bugs only against a single package. It makes it easier on the Firefox maintainers not to have to keep bugs open despite having fixed the problem on their end because the OOo maintainers are still working on their fix.

I'm editing this report to pertain only to Firefox since there is already an OOo report on the books.

[Chris Wilson (notgary-deactivatedaccount)]

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Ubuntu/10.10 Chromium/8.0.552.224 Chrome/8.0.552.224 Safari/534.10
Build Identifier:

Originally reported at https://bugs.launchpad.net/hundredpapercuts/+bug/597825

There is no need to display menu accelerators until the Alt key is pressed. Having them visible 'normally' is unsightly and unprofessional looking.

Reproducible: Always

[Enn (enndeakin)]

*** This bug has been marked as a duplicate of bug 25894 ***

[Enn (enndeakin)]

*** Bug 625910 has been marked as a duplicate of this bug. ***

[Faaborg (faaborg)]

*** Bug 667831 has been marked as a duplicate of this bug. ***

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Wilson (notgary-deactivatedaccount)]

I've just tested this on 12.04 and the accelerators are hidden by default, and only reveal themselves by pressing the Alt key. This appears to have been fixed.

[Dao (dao)]

*** Bug 776848 has been marked as a duplicate of this bug. ***

[Björn Michaelsen (bjoern-michaelsen)]

wontfix for unity as menubar makes this an nonissue.

[Dao (dao)]

*** Bug 852462 has been marked as a duplicate of this bug. ***

[Ge3k0s (ge3k0s)]

This is shown on Australis mockups. Need to know if it's part of the specs or not.

[Shorlander (shorlander)]

(In reply to Guillaume C. [:ge3k0s] from comment #79)
> This is shown on Australis mockups. Need to know if it's part of the specs
> or not.

I don't think any thinking has changed here. We should respect system defaults and settings. The only new information I can think of here is that from Windows 7 (maybe Vista?) forward the option for this is off by default and you have to opt-in by checking "Underline the keyboard shortcuts and access keys"

[Ge3k0s (ge3k0s)]

So this bug concerns all version of Windows. The title should be changed (especially since Windows 2000 isn't supported anymore). Could this bug be selected for the backlog ?

[Enn (enndeakin)]

The Windows api protion of this is already complete. What needs to be done here is:

- update nsTextBoxFrame to only draw accelerators when its window says as much from nsGlobalWindow::GetKeyboardIndicators.
- update the label-control binding
- handle when the alt key is pressed/released (and any other shortcuts that affect the accesskey display)
- update menu handling for when a menu bar is active/visible

[Ge3k0s (ge3k0s)]

Could this be considered as part of Photon redesign ?

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

We hide the menubar by default and have lived with this for nearly 20 years. I don't think it needs priority right now - we have enough on our plate as part of the Photon backlog.

[Ge3k0s (ge3k0s)]

(In reply to :Gijs from comment #84)
> We hide the menubar by default and have lived with this for nearly 20 years.
> I don't think it needs priority right now - we have enough on our plate as
> part of the Photon backlog.

I was thinking more about all the other places in the UI where these underlined letters still live (as you said for 20 years so clearly for too long), but I understand that Photon has already a big scope.

[Release-mgmt-account-bot (release-mgmt-account-bot)]

The severity field for this bug is relatively low, S3. However, the bug has 7 duplicates, 24 votes and 56 CCs.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#severity_underestimated.py).

[Autonag-nomail-bot (autonag-nomail-bot)]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

[Pulsebot-d (pulsebot-d)]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/8561bba0d491
[fenix] For https://github.com/mozilla-mobile/fenix/issues/25894 - Add firefox suggest header for lib suggestions