[10.5] Command+? should open OS X Leopard's new Help Menu Search

NEW
Unassigned

Status

()

Core
Widget: Cocoa
P3
normal
10 years ago
7 years ago

People

(Reporter: Louise, Unassigned)

Tracking

({regression})

Trunk
All
Mac OS X
regression
Points:
---
Bug Flags:
wanted1.9.1 +
wanted1.9.0.x -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021504 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021504 Minefield/3.0b4pre

Command+? (Command+Shift+/) should move focus to the search box in the Help menu for this is the normal behaviour of Mac apps.

Reproducible: Always

Steps to Reproduce:
1.Hit Command+? (Command+Shift+/ in English keyboard)

Actual Results:  
nothing happens

Expected Results:  
move focus to the search box in the Help menu.
(Reporter)

Updated

10 years ago
Version: unspecified → Trunk
(Reporter)

Updated

10 years ago
Summary: Command+? should show search in Help menu → [cocoa] Command+? should show search in Help menu

Comment 1

10 years ago
There is no search box in the Help menu.
The Help menu is the rightmost menu in the main browser window containing these items:
  Help Contents
  ...
  Check for Updates
  About Minefield

Do you mean the Help window ("Welcome to Minefield Help")?
(Reporter)

Comment 2

10 years ago
I was talking about the "help menu search" as described in the page below.
http://www.apple.com/macosx/features/300.html#ical

I do see a blue search box in help menu

Comment 3

10 years ago
Can you attach a screenshot of Minefield showing this Help Menu Search?

I can't imagine this search returning any results for Minefield because we're using our own Help viewer.
Summary: [cocoa] Command+? should show search in Help menu → [10.5] Command+? should open OS X Leopards' new Help Menu Search

Updated

10 years ago
Summary: [10.5] Command+? should open OS X Leopards' new Help Menu Search → [10.5] Command+? should open OS X Leopard's new Help Menu Search
(Reporter)

Comment 4

10 years ago
Created attachment 307207 [details]
screenshot of help-menu-search in OS X 10.5 Leopard

Here is the screenshot.

Comment 5

10 years ago
Steffen: Leopard rebuilds the help menu and adds a search box to it. In this search box you can search for, for example, menuobjects in your app.

Louise: What app opens the help menu and puts focus in the search box when you press cmd+? (cmd+shift+/ with en-US kb). Firefox et al currently opens the Help Viewer, which is the correct behavior afaik.
(Reporter)

Comment 6

10 years ago
(In reply to comment #5)
> Louise: What app opens the help menu and puts focus in the search box when you
> press cmd+? (cmd+shift+/ with en-US kb). Firefox et al currently opens the Help
> Viewer, which is the correct behavior afaik.
> 

Checked with
Finder,Safari,iTunes,TextEdit,SoftwareUpdate,Applicatin Monitor and Console.

It gives me the impression that putting focus on help-menu-search with command+?(command+shift+/) is the default behaviour for Leopard(10.5) since most of the main applications work that way.

btw, Cmd+? doesn't open Help Viewer on Leopard either.

Comment 7

10 years ago
Hmm, this is interesting. I'm using a Swedish Leopard and pressing cmd+shift++ (which is equialent to cmd+?) opens the help viewer for me. If I switch to en-US input and press the en-US cmd+shift+/, only the Help menu opens. So, It looks like you're right.

Comment 8

10 years ago
(tested with Finder)
(Reporter)

Comment 9

10 years ago
(In reply to comment #7)
> Hmm, this is interesting. I'm using a Swedish Leopard and pressing cmd+shift++
> (which is equialent to cmd+?) opens the help viewer for me. If I switch to
> en-US input and press the en-US cmd+shift+/, only the Help menu opens. So, It
> looks like you're right.
> 
Could that be a bug on Leopard's side?  Cmd+? working differently on keyboards other than en-US?

In that case, what will be the right thing to do for Firefox?
With en-US, Firefox's behaviour is pretty inconsistent.

Comment 10

10 years ago
Apple refers to cmd+? as a key combo for opening the help viewer, see http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGKeyboardShortcuts/chapter_950_section_1.html

The problem here is that *if* the current behavior on en-US Leopard is correct, you'll have to consider that the behavior on Tiger is different. And also different on (possibly all) non-english versions of Leopard (maybe that is a bug?)...
(Reporter)

Comment 11

10 years ago
Should I file another bug for Help viewer not working in Leopard with en-US keyboard?

Comment 12

10 years ago
I think we need to find out whether the new behavior in Leopard is a bug or whether the behavior in (at least my sv-SE version) non-english versions is a bug.

Comment 13

10 years ago
That said, it's not that likely that the new behavior is a bug. But I'm a bit confused over the fact that it differs between en-US and sv-SE...
(Reporter)

Comment 14

10 years ago
(In reply to comment #12)
> I think we need to find out whether the new behavior in Leopard is a bug or
> whether the behavior in (at least my sv-SE version) non-english versions is a
> bug.
> 
I couldn't find this keyboard shortcut referred to in Apple's Human Interface Guideline (which they've recently updated).

I can only assume this is the preferred behaviour given that Finder, Safari and other applications that comes bundled with 10.5 work that way and that it not working in non-english keyboard layout is a bug of OS X..




Comment 15

10 years ago
> I couldn't find this keyboard shortcut referred to in Apple's Human Interface
> Guideline

See comment #10?

(Reporter)

Comment 16

10 years ago
(In reply to comment #15)
> > I couldn't find this keyboard shortcut referred to in Apple's Human Interface
> > Guideline
> 
> See comment #10?
> 
right, excuse me.  please forget about my previous comment #14.

Comment 17

10 years ago
I can confirm on 10.5 Japanese environment.

(In reply to comment #0)
> Command+? (Command+Shift+/) should move focus to the search box in the Help
> menu for this is the normal behaviour of Mac apps.

This shortcut key may be differret.
It depends on [System Preferences] -> [Keyboard & Mouse] -> [Keyboard Shortcuts] -> [Show Help Menu].

If Firefox uses same shortcut key, the shortcut should be overrided with [Show Help Menu].
But now, maybe after Bug 398514, Firefox's shortcut works instead of [Show Help Menu].

I think this is not Firefox's bug, but widget's bug.

Comment 18

10 years ago
(In reply to comment #17)
> I can confirm on 10.5 Japanese environment.

Oops, this means "move focus to the search box in the Help menu." does not work.
But cause of this is different between comment #0 and comment #17.

Comment 19

10 years ago
To clarify:

Cmd+Shift+/ must be pressed to press Cmd+? in some keyboard layout,
and Cmd+Shift+/ and Cmd+? are equivalent in some cases,
but must be distinguished in other cases.
Thus pressing Cmd+? in Swedish keyboard can not open Help Menu.

Steps to Reproduce:
1. Use OS X 10.5.x.
2. Use keyboard layout in which "?" is "Shift+/"
   e.g. U.S., Canadian English, British, Australian, ...
3. Open [System Preferences] -> [Keyboard & Mouse] -> [Keyboard Shortcuts]
   and make sure shortcut of [Show Help Menu] is "⇧⌘/".
   If not, change it to "⇧⌘/".
4. Start Firefox.
5. Press Cmd+Shift+/

Actual Result:
Help Menu does not open.

Expected Result:
Help Menu opens.

Is this same as the intention of this bug?
If so, I think this is not Firefox's bug, but Core/Widget:Cocoa's bug.
(Reporter)

Comment 20

10 years ago
(In reply to comment #19)
> Steps to Reproduce:
> 1. Use OS X 10.5.x.
> 2. Use keyboard layout in which "?" is "Shift+/"
>    e.g. U.S., Canadian English, British, Australian, ...
> 3. Open [System Preferences] -> [Keyboard & Mouse] -> [Keyboard Shortcuts]
>    and make sure shortcut of [Show Help Menu] is "⇧⌘/".
>    If not, change it to "⇧⌘/".
> 4. Start Firefox.
> 5. Press Cmd+Shift+/
> 
> Actual Result:
> Help Menu does not open.
> 
> Expected Result:
> Help Menu opens.
> 
> Is this same as the intention of this bug?
> If so, I think this is not Firefox's bug, but Core/Widget:Cocoa's bug.
> 

I can't recall exactly from when but at some point, the behaviour of Cmd+Shift+/ must have changed, since now it seems to open http://www.mozilla.org/support/inproduct whereas it used to do nothing at all.

I'm using a US keyboard and shortcut preference is set as you mentioned (by default).  
I still think Cmd+? should focus the help-menu-search.  The Help page that is opened now could be easily accessed through help menu anyway.

Comment 21

10 years ago
(In reply to comment #20) 
> I still think Cmd+? should focus the help-menu-search.

Why "Cmd+?"?
By default, the shortcut is "⇧⌘/", i.e. "Cmd+Shift+/".
Cmd+? and Cmd+Shift+/ must be distinguished on some cases.
Summary should be "[10.5] Command+Shift+/ should open OS X Leopard's new Help Menu Search."

Anyway, if you think Cmd+Shift+/ should focus the help-menu-search, I think this is not Firefox's bug.
I suggest move product/component of this bug to Core/Widget: Cocoa.
(Reporter)

Comment 22

10 years ago
(In reply to comment #21)
> (In reply to comment #20) 
> > I still think Cmd+? should focus the help-menu-search.
> 
> Why "Cmd+?"?

I didn't mean to say Cmd+? rather than Cmd+Shift+/.  
But since the shortcut is editable via OS X preference, it might be better to morph the title to something like "Show help menu (default:Cmd+Shift+/) should focus help-menu-search"
This worked as recently as the 2008-04-14-04-trunk Minefield nightly
(Cmd-Shift-/ does open the Help menu and put the focus in its Seach
field in that nightly).  It stopped working again in the
2008-04-15-04-trunk Minefield nightly.

So probably triggered/caused by the patch for bug 359638.
Assignee: nobody → joshmoz
Component: OS Integration → Widget: Cocoa
Product: Firefox → Core
QA Contact: os.integration → cocoa
Status: UNCONFIRMED → NEW
Ever confirmed: true
Furthermore, Cmd-Shift-/ works properly in today's Camino trunk
nightly, Firefox 2.0.0.14 and Camino 1.6.
Flags: wanted1.9.0.x?
Keywords: regression

Comment 25

10 years ago
JFTR:

browser/base/content/baseMenuOverlay.xul
115 #ifdef XP_MACOSX
116 <!-- On mac, we map Cmd+Shift+/, but show Cmd+?
117      (that's for en-US, it might be different for other keyboard layouts) -->
118         <key id="key_openHelpMac"
119              oncommand="openHelpLink('firefox-help');"
120              key="&openHelpMac.commandkey;"
121              modifiers="&openHelpMac.modifiers;"/>
122         <key id="key_openHelpMacFrontend"
123              key="&openHelpMac.frontendCommandkey;"
124              modifiers="&openHelpMac.frontendModifiers;"/>

So, the actual shortcut keys are cmd+shift+/, but we just show cmd+? in the menu

Comment 26

10 years ago
(In reply to comment #23)
> It stopped working again in the
> 2008-04-15-04-trunk Minefield nightly.
> 
> So probably triggered/caused by the patch for bug 359638.

If Show Help Menu shortcut is the key that Firefox does not use,
Show Help Menu key does open the Help menu and focus it even in current nightly.
I guess the problem is collision of shortcut between Firefox and Show Help Menu.
Before Bug 359638, collision does not occur because Firefox's Cmd+Shift+something(Cmd+Shift+/ in this case) does not work at all.

So I think Bug 359638 is only trigger, and the root cause is the priority of shortcut between Firefox and Show Help Menu.

Comment 27

10 years ago
Isn't the reason for focusing the search field that you can then search the application help files? If it is, I'm a bit unsure if Firefox et al should focus the search field since iiuc a search won't really return any results from Help...
(Reporter)

Comment 28

10 years ago
(In reply to comment #27)
> Isn't the reason for focusing the search field that you can then search the
> application help files? If it is, I'm a bit unsure if Firefox et al should
> focus the search field since iiuc a search won't really return any results from
> Help...
> 

it was a nice way to access menus from keyboard but maybe you are right.   

Comment 29

10 years ago
Re garding the discussion Louise and I had about the different behavior in en-US and sv-SE versions of Leopard: This is of course because the Help menu shortcut in the OS is cmd+shift+/ even in sv-SE versions and this doesn't conflict with the cmd+? (which is eq to cmd+shift++ on sv-SE).

Comment 30

10 years ago
(In reply to comment #25)
> So, the actual shortcut keys are cmd+shift+/, but we just show cmd+? in the
menu

Cmd+Shift+/ was removed by Bug 432112 landing, and the actual shotcutkey for Minfield Help is Cmd+? now.

Comment 31

10 years ago
> Cmd+Shift+/ was removed by Bug 432112 landing, and the actual shotcutkey for
> Minfield Help is Cmd+? now.

Oh, rather big change here...

Not wanted for 1.9.0.x, but possibly for 1.9.1?
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x-

Updated

10 years ago
Flags: wanted1.9.1? → wanted1.9.1+

Updated

9 years ago
Priority: -- → P3
Hardware: PowerPC → All

Updated

9 years ago
Assignee: joshmoz → nobody

Comment 33

8 years ago
I found a new twist on this. cmd+? works as expected if no windows are currently open, but brings up minefield help if a window IS open.

(In reply to comment #28)
> (In reply to comment #27)
> > Isn't the reason for focusing the search field that you can then search the
> > application help files? If it is, I'm a bit unsure if Firefox et al should
> > focus the search field since iiuc a search won't really return any results from
> > Help...
> > 
> 
> it was a nice way to access menus from keyboard but maybe you are right.   

I personally use this functionality almost exclusively to quickly find menu items in various programs. I know lots of people who use it this way across the OS. This is very useful if you can remember that a command exists but not what menu it's in - especially useful if you have the web dev tools installed.
Duplicate of this bug: 454092

Comment 35

7 years ago
This WFM in Firefox 4b11, Snow Leopard, Dutch or English keyboard layout.
You need to log in before you can comment on or make changes to this bug.