381982 - Inconsistent behaviour of optgroups

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Morten Nilsen]

Attachment: Minimal testcase in valid XHTML 1.1

Using Seamonkey 1.1.1, the first optgroup label of a select selects the first option when clicked, while the second optgroup label does nothing when clicked.

XHTML testcase attached.

Comment 1

[Samuel Sidler (old account; do not CC)]

Morten, what behavior exists in a trunk build?

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 2

[Morten Nilsen]

Installed and tested, same behavior as described above found.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The difference is that when trying to find the clicked-on option, the code does:

  // If the event coordinate is above the first option frame, then target the
  // first option frame

So if you click the first optgroup, that targets the first option, since you're clicking above it.  However, if you click on the second optgroup, we end up with no option targeted.

You'd get similar behavior if you had an empty optgroup at the end: we'd select the _last_ option, due to:

  // If the event coordinate is below the last option frame, then target the
  // last option frame

I suppose we could explicitly make targeting an optgroup target its first option.  Is that the behavior we want?

Comment 4

[Morten Nilsen]

I'd say it might make sense to have the optgroup select all it's items when clicked.. but not so if just dragged across or shift-selected across..

Comment 5

[Boris Zbarsky [:bzbarsky]]

And if it's not a <select multiple> ?

Comment 6

[Morten Nilsen]

If we make it select all its members when multiple, the only sensible thing to do in a single select case, is not to select anything at all.. in my opinion.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Frankly, I think the "not select anything at all" behavior is what we want in general.  It's simple, consistent, and has no surprises for the user.

Comment 8

[Mats Palmgren (inactive)]

Attachment: Tetscase #2

Comment 9

[Mats Palmgren (inactive)]

(In reply to comment #7)
> Frankly, I think the "not select anything at all" behavior is what we want in
> general.  It's simple, consistent, and has no surprises for the user.

I agree.  That is also somewhat compatible with what IE7 and Safari does.
Opera 9.20 seems more like our current behaviour - it selects what
is nearest.  There is one case where I think we should do something
when clicking on a group label; when selecting a range of options in a
multi-select list (ie. SHIFT+click) we should add all the non-disabled
options up to that point - this is also what IE7, Safari and Opera does.
It's also consistent with what happens when you SHIFT+click on a
disabled option.  Other than that I don't think we should do any
selection, just focus the list, as if we clicked on some other non-
option area of the list (padding/border/scrollbar/disabled option).

Comment 10

[Mats Palmgren (inactive)]

Attachment: Patch rev. 1

I'll file a separate bug on the SHIFT+click thing mentioned above.

Comment 11

[Mats Palmgren (inactive)]

Note on compat:
IE7 - clicking on a group label in a multi-select list deselects all items,
this seems like a bug since it doesn't do anything in a single-select list.
Opera 9.20 - using SHIFT+click you can select disabled options in a
multi-select list, clearly a bug.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 276289 [details] [diff] [review]
Patch rev. 1

This would regress bug 290428.

Comment 13

[Boris Zbarsky [:bzbarsky]]

I'd prefer it if we added explicit checks for clicking on an optgroup, for what it' worth.

Comment 14

[Boris Zbarsky [:bzbarsky]]

And even then, we should watch out for bug 290428 with optgroups.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.