Closed
Bug 108372
Opened 24 years ago
Closed 24 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•24 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: 24 years ago
Resolution: --- → DUPLICATE
Comment 2•24 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•24 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•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
Comment 4•24 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: 24 years ago → 24 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
•