Closed Bug 305479 Opened 16 years ago Closed 15 years ago

Cmd+, needs to be pressed twice to access Preferences (on Mac)

Categories

(Core Graveyard :: Widget: Mac, defect)

PowerPC
macOS
defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kamikazow, Assigned: mark)

References

Details

(Keywords: fixed1.8.1)

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050816 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050816 Firefox/1.0+

The Command-, shortcut doesn't work on the first time. It's needed to be pressed
twice to access Preferences. After accessing Preferences for the first time
using the shortcut, a single Cmd-, is enough as long as Firefox is not closed
and restarted.

This also happens on Thunderbird 1.0.5 (20050711).

Reproducible: Always

Steps to Reproduce:
1. Close Firefox
2. Restart Firefox
3. Press Cmd-, the first time
4. Press Cmd-, a second time time
Actual Results:  
Preferences don't open on the first try

Expected Results:  
Preferences do open on the first try
Confirmed Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4)
Gecko/20050821 Firefox/1.0+ using the steps in comment 0.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b4?
This is old. Happens in Mozilla 1.8a4. Something to do with the way mac menus
are implemented?
Assignee: nobody → joshmoz
Component: Keyboard Navigation → Widget: Mac
Product: Firefox → Core
QA Contact: keyboard.navigation → mac
Version: unspecified → Trunk
Flags: blocking1.8b4? → blocking1.8b4-
I also have this issue in Komodo.  I've verified in Firefox 1.5b1.  A further
note, if you use another menu command first (eg. cmd+I) then you DO NOT need to
do cmd+, twice to get the prefs panel.  So the problem is only if the first menu
command you try is prefs.
*** Bug 325734 has been marked as a duplicate of this bug. ***
Assignee: joshmoz → mark
Attached patch PatchSplinter Review
This patch is much simpler than it looks.  The CommandEventHandler method was able to lose a switch statement, so there's some reindentation going on.  I'll attach a diff -w to make it easier to see what's happening.
Attachment #218321 - Flags: review?(joshmoz)
Attached patch (with diff -w)Splinter Review
Attachment #218321 - Flags: review?(joshmoz) → review+
Attachment #218321 - Flags: superreview?(mikepinkerton)
+    if (mPrefItemContent)
+      ::EnableMenuCommand(NULL, kHICommandPreferences);

so this is really the fix, or did i missing something?
Comment on attachment 218321 [details] [diff] [review]
Patch

sr=pink
Attachment #218321 - Flags: superreview?(mikepinkerton) → superreview+
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Attachment #218321 - Flags: approval-branch-1.8.1+
Comment on attachment 218321 [details] [diff] [review]
Patch

1.8.1 needs a patch edited for context.
Attachment #218321 - Flags: approval-branch-1.8.1+
Attached patch Branch versionSplinter Review
Attachment #219684 - Flags: approval-branch-1.8.1+
Fixed on MOZILLA_1_8_BRANCH.
Keywords: fixed1.8.1
*** Bug 329024 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.