Closed
Bug 108372
Opened 23 years ago
Closed 23 years ago
Command-H maps to two different menu selections
Categories
(Core :: XUL, defect)
Tracking
()
mozilla1.1alpha
People
(Reporter: pgauriar, Assigned: hyatt)
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.5) Gecko/20011015 BuildID: 2001110208 If you hit Command-H before going to the Tools submenu of the Tasks menu in the menubar, the application will hide. After you've viewed the aforementioned submenu, Command-H will bring up the History Window. This behavior will continue until you quit Mozilla. Reproducible: Always Steps to Reproduce: 1. Launch Mozilla 2. Hit Command-H 3. Un-Hide Mozilla by clicking on the Dock icon 4. Go to the Tasks menu in the menubar, and mouse down to the Tools submenu 5. Leave the menu, and press the key combination Command-H. Actual Results: After hitting Command-H the first time, Mozilla hides itself. After viewing the Tools submenu, Command-H brings up the History window. Expected Results: Command-H should either always hide the application or always bring up the History window. Not both. I think this bug depends on Bug 74244. We have to decide whether we want to hide the application or bring up the History window with Command-H before we can assign a definite behavior in the menus. FYI: Apple's Human Interface Guidelines require that Command-H be reserved for application hiding.
Comment 1•23 years ago
|
||
Duplicate of "Shortcut for History (Command-H) collides with Hide (OS-reserved)" *** This bug has been marked as a duplicate of 74244 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 2•23 years ago
|
||
Comments from reporter: I don't think this is a duplicate. Bug 74244 says that by using Command-H for history, we are breaking Apple's HIG (it should map to Hide Mozilla), and that we should change the shortcut for the history. My bug is that the behavior of Command-H changes depending on whether you've viewed a particular menu (Tasks:Tools) or not. These aren't the same thing. I would like you to reconsider marking this as duplicate.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 3•23 years ago
|
||
Setting status to NEW. Why are we clobbering the global binding when the menu is viewed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Comment 4•23 years ago
|
||
It is a dupe. The reason you get a different behavior depending on whether or not the Tools submenu has been displayed is that we dynamically build the menus. The OS doesn't realize we have a menu item w/cmd-h until we build it so it it finds the system defined Hide. *** This bug has been marked as a duplicate of 74244 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•