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.akhg...@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.akhg...@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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/597825 Title: Menu accelerators in Firefox don't follow the GNOME policy. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
