[Bug 597825] Re: Menu accelerators in Firefox don't follow the GNOME policy.

Bug Watch Updater 597825 at bugs.launchpad.net
Tue Jan 25 07:41:49 UTC 2011


Launchpad has imported 76 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=25894.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2000-01-31T18:06:01+00:00 Cpratt-formerly-netscape wrote:

Build ID: 2000012812
Platform: Windows 2000 only

To reproduce:

- On Windows 2000, launch mozilla.exe.

Result: Keyboard accelerators in the application menu are underlined.

Expected result: They should not be underlined until the Alt key is
pressed.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/0

------------------------------------------------------------------------
On 2000-02-03T01:57:32+00:00 Shuang wrote:

Who should own this?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/1

------------------------------------------------------------------------
On 2000-02-03T02:02:55+00:00 Elig wrote:

That's the easy part. ;)


Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/2

------------------------------------------------------------------------
On 2000-02-03T04:44:37+00:00 Mikepinkerton wrote:

accepting, m20.


Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/3

------------------------------------------------------------------------
On 2000-02-11T07:00:47+00:00 Mpt-postinbox wrote:

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.)

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/4

------------------------------------------------------------------------
On 2000-04-05T01:29:17+00:00 Trudelle wrote:

Mass move of all M20 bugs to M30.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/5

------------------------------------------------------------------------
On 2000-04-05T02:06:00+00:00 Trudelle wrote:

Mass moving M20 bugs to M30

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/6

------------------------------------------------------------------------
On 2000-04-12T21:36:37+00:00 Dean-tessman wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/7

------------------------------------------------------------------------
On 2000-05-03T05:40:52+00:00 Timeless-bemail wrote:

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]

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/8

------------------------------------------------------------------------
On 2000-05-03T05:59:25+00:00 Timeless-bemail wrote:

oops i didn't mean to do that.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/9

------------------------------------------------------------------------
On 2000-05-03T07:01:27+00:00 Dean-tessman wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/10

------------------------------------------------------------------------
On 2000-05-04T06:11:20+00:00 Dean-tessman wrote:

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?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/11

------------------------------------------------------------------------
On 2000-05-25T22:24:12+00:00 Trudelle wrote:

Mass-moving all M20-M30 XPToolkit bugs to Future

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/12

------------------------------------------------------------------------
On 2000-05-31T16:56:27+00:00 Bugzilla-iwaruna wrote:

*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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/13

------------------------------------------------------------------------
On 2000-09-03T21:14:05+00:00 Timeless-bemail wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/14

------------------------------------------------------------------------
On 2000-09-03T21:32:37+00:00 Dean-tessman wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/15

------------------------------------------------------------------------
On 2000-09-03T23:45:02+00:00 Timeless-bemail wrote:

Ben says hyatt or evaughan.
Hyatt?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/16

------------------------------------------------------------------------
On 2000-10-26T06:36:51+00:00 Dean-tessman wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/17

------------------------------------------------------------------------
On 2000-11-28T22:07:40+00:00 Bugzilla-blakeross wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/18

------------------------------------------------------------------------
On 2000-12-08T04:33:07+00:00 Bugzilla-blakeross wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/19

------------------------------------------------------------------------
On 2001-02-01T22:01:17+00:00 Mpt-postinbox wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/20

------------------------------------------------------------------------
On 2002-01-20T07:02:07+00:00 Bugzilla-blakeross wrote:

reassigning to default owner.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/21

------------------------------------------------------------------------
On 2002-04-15T15:32:37+00:00 James Ross wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/22

------------------------------------------------------------------------
On 2002-09-25T19:33:45+00:00 Dean-tessman wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/23

------------------------------------------------------------------------
On 2002-09-27T08:26:00+00:00 Nnbugzilla wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/24

------------------------------------------------------------------------
On 2002-09-27T09:55:42+00:00 Timeless-bemail wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/25

------------------------------------------------------------------------
On 2003-04-18T15:35:53+00:00 swalker wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/26

------------------------------------------------------------------------
On 2003-04-18T15:47:47+00:00 Muellkontrolle wrote:

@owner: Same on Windows XP

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/27

------------------------------------------------------------------------
On 2003-12-22T10:32:26+00:00 Prognathous wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/28

------------------------------------------------------------------------
On 2003-12-22T10:50:25+00:00 Prognathous wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/29

------------------------------------------------------------------------
On 2003-12-22T12:08:40+00:00 Tsahi-75 wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/30

------------------------------------------------------------------------
On 2003-12-22T12:48:01+00:00 Prognathous wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/31

------------------------------------------------------------------------
On 2003-12-22T14:56:11+00:00 Tsahi-75 wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/32

------------------------------------------------------------------------
On 2003-12-22T17:14:24+00:00 Prognathous wrote:

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.


Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/33

------------------------------------------------------------------------
On 2005-01-13T12:07:09+00:00 Mano-mozilla wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/34

------------------------------------------------------------------------
On 2005-03-12T10:57:47+00:00 Jruderman wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/35

------------------------------------------------------------------------
On 2008-09-23T15:42:54+00:00 Random4444+bugzilla wrote:

(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...

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/36

------------------------------------------------------------------------
On 2008-09-23T16:15:50+00:00 Random4444+bugzilla wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/37

------------------------------------------------------------------------
On 2008-09-25T15:50:58+00:00 Ehsan-mozilla wrote:

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?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/38

------------------------------------------------------------------------
On 2008-09-26T22:06:28+00:00 Stream wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/39

------------------------------------------------------------------------
On 2008-09-26T22:09:07+00:00 Stream wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/40

------------------------------------------------------------------------
On 2008-10-08T16:34:22+00:00 Ehsan-mozilla wrote:

Created attachment 342259
WIP

Here's my work in progress which doesn't work completely.  I've run into
some problems with this patch, which I asked about here
<http://groups.google.com/group/microsoft.public.win32.programmer.ui/browse_thread/thread/fdfcaf203c28a8fb#>
but I haven't got any replies yet.

I won't have enough time to work on this for some time, but if someone
else wants to step up, that would be great.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/41

------------------------------------------------------------------------
On 2008-10-29T06:07:30+00:00 Faaborg wrote:

this bug is eligible for bug 462080

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/42

------------------------------------------------------------------------
On 2008-10-29T12:38:07+00:00 Bugzilla-pdjs wrote:

Qt4 on Windows seems to hide/show accesskeys when Alt is pressed. I
don't know how correctly/hackishly it's implemented, but it might be
worth looking at how they do it.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/43

------------------------------------------------------------------------
On 2008-10-30T05:16:08+00:00 Timeless-bemail wrote:

http://groups.google.com/group/microsoft.public.win32.programmer.ui/browse_thread/thread/ccc6cfeb44423ee2/c51ac91dc66e03f8?lnk=gst&q=WM_UPDATEUISTATE#c51ac91dc66e03f8

seems like you get to fire the event yourself. If that's not the right
answer, there's a guy from discussions.microsoft.com who's been
answering questions about it.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/44

------------------------------------------------------------------------
On 2009-01-25T22:16:38+00:00 Ehsan-mozilla wrote:

Created attachment 358759
WIP 2

I've made great progress on this patch thanks for the ReactOS
implementation of the UI state messages
<http://www.google.com/codesearch/p?hl=en#w0bYSBcdNg8/reactos/dll/win32/user32/windows/defwnd.c&l=1608>.

Things kind of work correctly now.  The initial UI doesn't show
accelerators according to the OS settings, and pressing Alt makes them
appear, and pressing Alt again makes them disappear.

One important thing which remains to be solved is showing the access
keys by default when the window has been opened via keyboard.  The code
is in place -- I just don't know which Win32 API to call to figure out
whether the last input message was a keyboard message or not
(lastInputMsgKeyboard TODO).  The ReactOS code
<http://www.google.com/codesearch/p?hl=en#w0bYSBcdNg8/reactos/dll/win32/user32/windows/defwnd.c&l=1647>
calls GetThreadDesktopInfo which seems to be a ReactOS specific kernel
level API.  Does anyone know of any Win32 API which I can use to
retrieve the same information?  (The odd thing is that logically this
should not work, but when testing, I see that it's working all the
time!)

Another thing which remains is handling all types of XUL frames (such as
check boxes and labels), but that is mostly a matter of figuring out
which frame classes implement them and handling the accesskey drawing
code there.  Pointers appreciated here!

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/45

------------------------------------------------------------------------
On 2009-01-25T22:17:37+00:00 Ehsan-mozilla wrote:

I have also submitted a try server build with the hideaccel identifier.
I'll post a link here when the build is finished.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/46

------------------------------------------------------------------------
On 2009-01-26T04:41:15+00:00 Ehsan-mozilla wrote:

Try server builds available at: <https://build.mozilla.org/tryserver-
builds/2009-01-25_14:05-ehsan.akhgari at gmail.com-hideaccel/>

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/47

------------------------------------------------------------------------
On 2009-01-26T07:35:14+00:00 Stream wrote:

I tried the build, but when i press alt and then use the mouse somewhere
else, the accelerators are still there.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/48

------------------------------------------------------------------------
On 2009-01-26T08:11:30+00:00 Ehsan-mozilla wrote:

(In reply to comment #48)
> I tried the build, but when i press alt and then use the mouse somewhere else,
> the accelerators are still there.

Hmm, I think I was mistaken on how the Alt pressing should work.  Here's
what should happen IINM:

If Alt is pressed on a Window with menus, the first menu should get
focus and accelerators should appear.  In this case, pressing Alt again
should turn off the accelerators again and the menu should lose focus.
Clicking mouse somewhere other than on the menus should also dismiss the
focus and turn off accelerators.

For windows without menus, pressing Alt should turn on accelerators, and
pressing Alt again or using the mouse will not turn off the access keys.

So, I guess the problem you observed was with the menus, right?  The
current patch mistakenly turns off accelerators when Alt is pressed for
the second time on any window.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/49

------------------------------------------------------------------------
On 2009-01-26T09:47:38+00:00 Stream wrote:

Not only with menus.
Its enough to just click somewhere and the focus will gone but the accelerators not.

That way its possible:
- to show context menu via mouse with accelerators shown.
(alt > right click, or alt > click > right click)

- if alt is pressed again for keyboard only navigation you can navigate
with the keyboard without any visible accelerators, because they are
visible pressing alt is hiding them. (alt > click > alt)

The problem is that the accelerators are not hided when there is mouse click.
They should disappear together with the focus.

Another thing which i saw is, if i use keyboard to open new window from
current window, the accelerator are shown in your build while on IE6,
IE7 and IE8 i didnt saw the same thing, they are not there even when the
window is opened from another window with the keyboard.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/50

------------------------------------------------------------------------
On 2009-01-26T10:12:01+00:00 Stream wrote:

The above was for clicks outside the menubar.

On Explorer for clicks on menubar:
Pressing alt and then mouse click opens the clicked menu, if there is second mouse click, it hides the accelerators and opens the clicked menu. If the second click is on the same menuitem the accelerators are gone and the menu is closed.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/51

------------------------------------------------------------------------
On 2009-01-26T17:09:24+00:00 Random4444+bugzilla wrote:

The alt key right now (in the test build) acts as a toggle - either
showing the underlines or not.  It should really be more temporary - alt
key only should enable access keys until that navigation set is
finished, anything other interaction should disable keyboard navigation
again.  The same for new windows with menus - keyboard navigation is
always disabled unless it is enabled specifically by alt again.  Windows
without menus are a little trickier - if they are opened by keyboard
navigation, they should also have keyboard navigation on?  I'm not sure
of correct behavior here, but that seems right to me (and matches IE's
behavior).

Next fix is probably to make sure mouse clicks lose focus and turn off
access keys.  If I can later, I'll look for where this would be done.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/52

------------------------------------------------------------------------
On 2009-01-27T19:45:12+00:00 Ehsan-mozilla wrote:

OK, it seems like the access key for XUL labels and check boxes is drawn
using an HTML span with class named accesskey, and all of this is done
in text.xul: <http://mxr.mozilla.org/mozilla-
central/source/toolkit/content/widgets/text.xml#87>.  This is a problem
since XUL content does not have access to the nsIWidget interface.

CCing Enn to see if he has an idea how to tie the nsIWidget-based
implementation and XUL text-label widget together.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/53

------------------------------------------------------------------------
On 2009-01-27T20:59:02+00:00 Ehsan-mozilla wrote:

Created attachment 359118
WIP 3

This patch fixes the Alt toggling problem.  I also attempted to fix the
menu and Alt key behavior, but it seems like the menu bar frame object
can't get access to a proper nsIWidget (nsWindow object).  If someone
can help me figure out how to access the nsWindow object from the menu
bar frame, that would be great.

I've submitted another try server build, and I'll post a link when it's
available.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/54

------------------------------------------------------------------------
On 2009-01-27T21:13:06+00:00 Enn wrote:

(In reply to comment #53)
> OK, it seems like the access key for XUL labels and check boxes is drawn using
> an HTML span with class named accesskey, and all of this is done in text.xul:
> <http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/text.xml#87>.
>  This is a problem since XUL content does not have access to the nsIWidget
> interface.

You could get the widget from the nsXULLabelFrame.

> I also attempted to fix the menu and Alt key behavior, but it seems
> like the menu bar frame object can't get access to a proper nsIWidget

Which widget are you getting and which one do you need?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/55

------------------------------------------------------------------------
On 2009-01-27T21:19:30+00:00 Ehsan-mozilla wrote:

(In reply to comment #55)
> (In reply to comment #53)
> > OK, it seems like the access key for XUL labels and check boxes is drawn using
> > an HTML span with class named accesskey, and all of this is done in text.xul:
> > <http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/text.xml#87>.
> >  This is a problem since XUL content does not have access to the nsIWidget
> > interface.
> 
> You could get the widget from the nsXULLabelFrame.

Hmmm, I have no idea how to do that from the XBL code...  And anyway,
nsIWidget is not XPCOM accessible, so it probably won't be enough to get
the widget in XBL.

> > I also attempted to fix the menu and Alt key behavior, but it seems
> > like the menu bar frame object can't get access to a proper nsIWidget
> 
> Which widget are you getting and which one do you need?

I'm not sure how to tell which widget I'm getting, but I need the window
widget (nsWindow).

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/56

------------------------------------------------------------------------
On 2009-01-27T21:28:37+00:00 Enn wrote:

(In reply to comment #56)
> 
> Hmmm, I have no idea how to do that from the XBL code...  And anyway, nsIWidget
> is not XPCOM accessible, so it probably won't be enough to get the widget in
> XBL.

nsXULLabelFrame is C++ code. You could make the xbl label portion
implement some interface for a callback to indicate that the accesskey
needs to be updated.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/57

------------------------------------------------------------------------
On 2009-01-28T19:13:15+00:00 Ehsan-mozilla wrote:

(In reply to comment #57)
> nsXULLabelFrame is C++ code. You could make the xbl label portion implement
> some interface for a callback to indicate that the accesskey needs to be
> updated.

Good idea.  I have one more question though.  Since this whole thing
should be done per window (not globally), is there any way in the XBL
code to differentiate between callbacks from other windows and callbacks
from the window in which the label is residing?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/58

------------------------------------------------------------------------
On 2009-01-28T22:50:58+00:00 Ehsan-mozilla wrote:

BTW, the try server builds for the last patch are available at:
<https://build.mozilla.org/tryserver-
builds/2009-01-27_13:00-ehsan.akhgari at gmail.com-hideaccel2/>.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/59

------------------------------------------------------------------------
On 2009-01-29T08:48:26+00:00 Dev-null-hotmail wrote:

As for Explorer,
- When I press the Application Key, accesskeys in the context menu are underlined.
- When I press Shift+F10, accesskeys in both the menubar and the context menu are underlined.

Should we simulate this?

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/60

------------------------------------------------------------------------
On 2009-03-30T20:54:45+00:00 Mike Connor wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/61

------------------------------------------------------------------------
On 2009-04-06T04:12:01+00:00 Timeless-bemail wrote:

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).

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/62

------------------------------------------------------------------------
On 2009-06-23T05:26:49+00:00 Faaborg wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/63

------------------------------------------------------------------------
On 2009-06-23T06:00:26+00:00 Faaborg wrote:

(switching to whiteboard for polish-relative priorities)

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/64

------------------------------------------------------------------------
On 2009-06-23T14:57:21+00:00 Beltzner wrote:

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)

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/65

------------------------------------------------------------------------
On 2009-06-23T15:14:51+00:00 Dao wrote:

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

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/66

------------------------------------------------------------------------
On 2009-06-23T19:48:39+00:00 Faaborg wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/67

------------------------------------------------------------------------
On 2009-06-23T19:52:28+00:00 Enn wrote:

(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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/68

------------------------------------------------------------------------
On 2009-06-23T19:55:03+00:00 Dao wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/69

------------------------------------------------------------------------
On 2009-06-24T00:12:30+00:00 Faaborg wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/70

------------------------------------------------------------------------
On 2009-07-05T17:42:10+00:00 Enn wrote:

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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/71

------------------------------------------------------------------------
On 2009-07-11T18:41:30+00:00 Ehsan-mozilla wrote:

(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.

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/72

------------------------------------------------------------------------
On 2010-03-18T00:15:22+00:00 Ehsan-mozilla wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/73

------------------------------------------------------------------------
On 2010-03-24T09:35:01+00:00 Dao wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/74

------------------------------------------------------------------------
On 2011-01-15T13:01:13+00:00 Enn wrote:

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

Reply at: https://bugs.launchpad.net/firefox/+bug/597825/comments/84


** Changed in: firefox
       Status: Unknown => Confirmed

** Changed in: firefox
   Importance: Unknown => Medium

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in ubuntu.
https://bugs.launchpad.net/bugs/597825

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




More information about the Ubuntu-mozillateam-bugs mailing list