400748 - [10.4] [10.5] optgroup form menu labels break keyboard selection

Status: RESOLVED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Nep]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.8) Gecko/20071010 Camino/1.5.2
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.8) Gecko/20071010 Camino/1.5.2

If you use optgroups in a select form element, it breaks keyboard selection for optgroups and options, too.

You should be able to activate the menu, and then type the letters corresponding to the beginning of an option to jump the menu to that item.  But if you use optgroups, this stops working. 

This does work properly in Firefox.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.hopstudios.com/camino_optgroup_bug.html
2. Activate the menu with keyboard (tab) or mouse (click)
3. Type a letter that matches an option.

Actual Results:  
Note that the expected option does not highlight.

Expected Results:  
The appropriate item should highlight.

Comment 1

[Stuart Morgan]

The OS controls that behavior. Unless we want to either remove support for option groups or go to a submenu approach (which I don't think we should), I doubt there's anything we can do about it.

Comment 2

[Nep]

Can you give an example of an OS menu that exhibits that same faulty behavior? Every menu I've found in the OS either jumps correctly when a keystroke is made, or doesn't respond to keystrokes at all.  None jump to the wrong place.

I'm wondering if many the form => OS menu conversion process is somehow faulty, or could be modified to produce better results.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: reporter's testcase, captured

This WFM in a recent branch nightly.

Comment 4

[philippe (part-time)]

WFM on Camino trunk when using tab + type a letter (J --> J-lab....).
Fails on the same trunk build when clicking on the widget with the mouse and typing J (goes to Real Baking....). The same happens on Cm 1.5.2.

And I see the same behaviour (mouse-click on the widget + type J --> Real Baking...) on Safari 2.04 and the latest WebKit build.

Comment 5

[Stuart Morgan]

(In reply to comment #2)
> Can you give an example of an OS menu that exhibits that same faulty behavior?

Yes: Safari, which is the only other place I'm aware that anyone tries to use
OS menus to create something that has the visual appearance we want for
optgroups.

> I'm wondering if many the form => OS menu conversion process is somehow faulty,
> or could be modified to produce better results.

As I said, we could remove the optgroup support, which would, I'm sure, give
correct keyboard navigation. That's not better though. The problem is that what
we do to give optgroups their appearance confuses the keyboard navigation
behavior provided by the OS.

If there were a solution for optgroup styling in menus that interacted better
with the OS menu implementation, presumably Safari would use it, which is why
I'm doubtful there is a good solution here. However, if you can provide working
code for a solution that has both useful visual grouping (without using
submenus) and behaves correctly with keyboard input, we'll gladly take it.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Ah, it's broken on 10.4, not 10.3; sounds like an OS bug to me, then.  Can someone check that-other-cat and see if the breakage persists, or if this is localized to 10.4 and we can potentially WF it.

Comment 7

[Stuart Morgan]

Yes, it's still broken.

Comment 8

[Chris Lawson (gone)]

Has anyone reported this to Apple?

Comment 9

[Chris Lawson (gone)]

Someone needs to file a rdar: on this if it hasn't happened already.

Comment 10

[Stuart Morgan]

Finally filed rdar://6918555.

Confirming and futuring for tracking (and on the offchance we ever start using non-native menus for this).

Comment 11

[Stuart Morgan]

Attachment: fix

I should have filed this with Apple a long time ago apparently; Eric Schlegel pointed me to an NSMenuItem API added in 10.3 for doing indentation without padding with spaces, which doesn't have this problem. Why Safari isn't using it I have no idea.

Comment 12

[Stuart Morgan]

It's such a simple fix, we may want to take it for 1.6.8 as well.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #12)
> It's such a simple fix, we may want to take it for 1.6.8 as well.

Assuming that API was not buggy in 10.3, yeah; someone please remind me to spin a build and test.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #13)
> (In reply to comment #12)
> > It's such a simple fix, we may want to take it for 1.6.8 as well.
> 
> Assuming that API was not buggy in 10.3, yeah; someone please remind me to spin
> a build and test.

I found nothing untoward in my testing, so let's take this if pink likes the patch ;)

Comment 15

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 380622 [details] [diff] [review]
fix

sr=pink

Comment 16

[Stuart Morgan]

Landed on trunk and MOZILLA_1_8_BRANCH.