Closed Bug 108372 Opened 23 years ago Closed 23 years ago

Command-H maps to two different menu selections

Categories

(Core :: XUL, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 74244
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.
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
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 → ---
Setting status to NEW.  Why are we clobbering the global binding when the menu
is viewed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1
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 ago23 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.