Open
Bug 25894
Opened 25 years ago
Updated 10 days ago
Keyboard accesskeys / mnemonics shouldn't be displayed on Windows if "Hide underlined letters" is checked
Categories
(Core :: XUL, defect)
Tracking
()
NEW
People
(Reporter: cpratt, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: helpwanted, platform-parity, polish, Whiteboard: [polish-hard] [polish-visual])
Attachments
(1 file, 2 obsolete files)
20.66 KB,
patch
|
Details | Diff | Splinter Review |
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.
Comment 1•25 years ago
|
||
Who should own this?
Comment 2•25 years ago
|
||
That's the easy part. ;)
Assignee: shuang → pinkerton
Component: UE/UI → XP Toolkit/Widgets: Menus
QA Contact: elig → sairuh
Comment 4•25 years ago
|
||
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.)
Updated•25 years ago
|
Keywords: pp
Summary: [PP] Keyboard accelerators display incorrectly in Windows 2000 → Keyboard accelerators display incorrectly in Windows 2000
Comment 5•24 years ago
|
||
Mass move of all M20 bugs to M30.
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.
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]
Keywords: pp
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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?
Comment 12•24 years ago
|
||
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Comment 13•24 years ago
|
||
*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.
QA Contact: sairuh → jrgm
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
Ugh. Any chance all of the accelerator key drawing is handled in one place?
Comment 16•24 years ago
|
||
Ben says hyatt or evaughan. Hyatt?
Updated•24 years ago
|
Keywords: helpwanted
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
I think I have this working. Stealing from mr. unresponsive module owner.
Assignee: pinkerton → blakeross
Status: ASSIGNED → NEW
Comment 19•24 years ago
|
||
Nothing like deleting your tree and forgetting to save a patch.
Status: NEW → ASSIGNED
Priority: P3 → P4
Target Milestone: Future → mozilla1.0
Comment 20•24 years ago
|
||
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.
Component: XP Toolkit/Widgets: Menus → XP Toolkit/Widgets
Summary: Keyboard accelerators display incorrectly in Windows 2000 → Keyboard accesskeys display incorrectly in Windows 2000
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 21•23 years ago
|
||
reassigning to default owner.
Assignee: blaker → jaggernaut
Status: ASSIGNED → NEW
Comment 22•22 years ago
|
||
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.
Comment 23•22 years ago
|
||
*** Bug 170029 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
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.
Comment 25•22 years ago
|
||
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.
Comment 26•21 years ago
|
||
*** Bug 202518 has been marked as a duplicate of this bug. ***
Comment 27•21 years ago
|
||
@owner: Same on Windows XP
Comment 28•21 years ago
|
||
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.
Comment 29•21 years ago
|
||
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.
Comment 30•21 years ago
|
||
accesskeys look like that in hebrew mozilla because of bug 162081.
Comment 31•21 years ago
|
||
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.
Comment 32•21 years ago
|
||
how does Win2k, or any other Win32, or other OSs, deal with it in those languages?
Comment 33•21 years ago
|
||
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.
Updated•20 years ago
|
Severity: trivial → normal
Summary: Keyboard accesskeys display incorrectly in Windows 2000 → Keyboard accesskeys / mnemonics shouldn't be displayed n Windows 2000 / XP if "Hide underlined letters" is checked
Comment 34•20 years ago
|
||
*** Bug 266733 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Summary: Keyboard accesskeys / mnemonics shouldn't be displayed n Windows 2000 / XP if "Hide underlined letters" is checked → Keyboard accesskeys / mnemonics shouldn't be displayed in Windows 2000 / XP if "Hide underlined letters" is checked
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Comment 35•19 years ago
|
||
*** Bug 285745 has been marked as a duplicate of this bug. ***
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Updated•16 years ago
|
QA Contact: jrgmorrison → xptoolkit.widgets
Comment 36•16 years ago
|
||
(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...
Comment 37•16 years ago
|
||
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.
Comment 38•16 years ago
|
||
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?
Comment 39•16 years ago
|
||
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
Comment 40•16 years ago
|
||
and WM_UPDATEUISTATE Message http://msdn.microsoft.com/en-us/library/ms646361(VS.85).aspx
Comment 41•16 years ago
|
||
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.
Comment 42•16 years ago
|
||
this bug is eligible for bug 462080
Keywords: polish
Whiteboard: [polish-hard] [polish-visual]
Comment 43•16 years ago
|
||
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.
Comment 44•16 years ago
|
||
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.
Updated•16 years ago
|
Assignee: jag → nobody
Comment 45•16 years ago
|
||
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!
Assignee: nobody → ehsan.akhgari
Attachment #342259 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Comment 46•16 years ago
|
||
I have also submitted a try server build with the hideaccel identifier. I'll post a link here when the build is finished.
Comment 47•16 years ago
|
||
Try server builds available at: <https://build.mozilla.org/tryserver-builds/2009-01-25_14:05-ehsan.akhgari@gmail.com-hideaccel/>
Comment 48•16 years ago
|
||
I tried the build, but when i press alt and then use the mouse somewhere else, the accelerators are still there.
Comment 49•16 years ago
|
||
(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.
Comment 50•16 years ago
|
||
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.
Comment 51•16 years ago
|
||
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.
Comment 52•16 years ago
|
||
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.
Comment 53•16 years ago
|
||
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.
Comment 54•16 years ago
|
||
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.
Attachment #358759 -
Attachment is obsolete: true
Comment 55•16 years ago
|
||
(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?
Comment 56•16 years ago
|
||
(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).
Comment 57•16 years ago
|
||
(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.
Comment 58•16 years ago
|
||
(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?
Comment 59•16 years ago
|
||
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@gmail.com-hideaccel2/>.
Comment 60•16 years ago
|
||
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?
Comment 62•15 years ago
|
||
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).
Comment 63•15 years ago
|
||
P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day.
Priority: P4 → P1
Updated•15 years ago
|
Whiteboard: [polish-hard] [polish-visual] → [polish-hard] [polish-visual][polish-p1]
Comment 65•15 years ago
|
||
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)
Whiteboard: [polish-hard] [polish-visual][polish-p1] → [polish-hard] [polish-visual][polish-p2]
Comment 66•15 years ago
|
||
(In reply to comment #65) > as this requires a specific setting The default setting is to hide the underlining, I think.
Comment 67•15 years ago
|
||
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.
Comment 68•15 years ago
|
||
(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.
Comment 69•15 years ago
|
||
That, and it would still be valid for other XUL apps with a menu bar.
Comment 70•15 years ago
|
||
yep, both good points. If bug 418521 gets resolved I think this bug is a decent contender for the P0.
Comment 71•15 years ago
|
||
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.
Comment 72•15 years ago
|
||
(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.
Comment 73•14 years ago
|
||
Updating to reality: I won't have the time to work on this for the foreseeable future!
Assignee: ehsan.akhgari → nobody
Status: ASSIGNED → NEW
Comment 74•14 years ago
|
||
See also http://blogs.fedoraproject.org/wp/mclasen/2010/03/24/mnemonics/ for GTK.
See Also: → https://launchpad.net/bugs/597825
Updated•13 years ago
|
Priority: P4 → --
Hardware: x86 → All
Target Milestone: Future → ---
Comment 79•11 years ago
|
||
This is shown on Australis mockups. Need to know if it's part of the specs or not.
Flags: needinfo?(shorlander)
Comment 80•11 years ago
|
||
(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"
Flags: needinfo?(shorlander)
Comment 81•10 years ago
|
||
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 ?
Comment 82•10 years ago
|
||
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
Updated•10 years ago
|
Flags: firefox-backlog?
Updated•10 years ago
|
Flags: firefox-backlog? → firefox-backlog+
Updated•10 years ago
|
Whiteboard: [polish-hard] [polish-visual][polish-p2] → [polish-hard] [polish-visual] p=8
Updated•10 years ago
|
Summary: Keyboard accesskeys / mnemonics shouldn't be displayed in Windows 2000 / XP if "Hide underlined letters" is checked → Keyboard accesskeys / mnemonics shouldn't be displayed on Windows if "Hide underlined letters" is checked
Updated•10 years ago
|
Points: --- → 8
Whiteboard: [polish-hard] [polish-visual] p=8 → [polish-hard] [polish-visual]
Comment 83•7 years ago
|
||
Could this be considered as part of Photon redesign ?
Flags: needinfo?(gijskruitbosch+bugs)
Comment 84•7 years ago
|
||
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.
Flags: needinfo?(gijskruitbosch+bugs)
Comment 85•7 years ago
|
||
(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.
Updated•2 years ago
|
Severity: normal → S3
Comment 86•2 years ago
|
||
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.
Flags: needinfo?(enndeakin)
Comment 87•2 years ago
|
||
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.
Flags: needinfo?(enndeakin)
Comment hidden (collapsed) |
Updated•10 days ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Updated•10 days ago
|
Status: REOPENED → NEW
You need to log in
before you can comment on or make changes to this bug.
Description
•