Open Bug 1767062 Opened 3 years ago Updated 3 years ago

Compat: Behavior of onclick for select elements is different from other browsers

Categories

(Core :: DOM: Events, defect, P3)

Product:
Core
Component:
DOM: Events
Version:
Firefox 98
Platform:
Desktop
All
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox101 --- affected

People

(Reporter: danielhunterjacobs, Unassigned)

References

Details

Attachments

(2 files)

Test case
524 bytes, text/html
Details
option click test
666 bytes, text/html
Details

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Created this page and tested how many times the click event triggered, using normal and accessible ways of choosing options:

<!DOCTYPE html>
<html>
<body>
<h1>Onclick select test</h1>
<label for="select">Select an option:</label>
<select id="select">
<option value="1">One</option>
<option value="2">Two</option>
</select>
<div>Total number of onclick events: <span id="output">0</span></div>
<script>
const select = document.getElementById("select");
const output = document.getElementById("output");
select.addEventListener("click", function() {
output.textContent = parseInt(output.textContent) + 1;
});
</script>
</body>
</html>

Actual results:

Every literal click triggered the click event. Firefox triggers onclick for the select between 0 and 2 times every time a selection is made. If the select is opened and the option is chosen using a mouse, onclick triggers twice. If the keyboard is used to both open the select and select the option, onclick triggers 0 times. If it's used for one of those functions while the mouse is used for the other one, it triggers once. This differs from Chromium's behavior, which I'd argue is better and more accessible.

Expected results:

What Chromium browsers do is trigger onclick for select elements only when an option is selected. This includes triggering the event when selection is made using the keyboard. When to fire onclick is arguable: you could argue it should fire both when opening the select and selecting an option, though I feel that's less useful and that doesn't match Chromium behavior. However, the onclick spec (https://w3c.github.io/uievents/#event-type-click) says In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, so keyboard selection should definitely fire the onclick event regardless of the ultimate decision about when onclick should be triggered.

Also, a somewhat related bug: option elements don't fire onclick events when selection is made with the keyboard (on Chromium, option element's don't fire onclick events at all, but here I think Firefox's behavior - aside from a lack of accessibility - is better).

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core
Component: Disability Access APIs → DOM: Events
Status: UNCONFIRMED → NEW
status-firefox101: --- → affected
Ever confirmed: true

Wondering about Safari's behavior. Asked QA to check and mention the result here.

Hey Mirko, tried on macOS 12.3.1 with Safari 15.4 and it seems that there is no count at all neither by clicking on the button or selecting with tab and enter on the test page. Here's an attachment with the behavior on Safari.

Thanks for testing Safari: created https://bugs.webkit.org/show_bug.cgi?id=239964

Attached file Test case —

However, the onclick spec (https://w3c.github.io/uievents/#event-type-click) says In addition to being associated with pointer devices, the click event type MUST be dispatched as part of an element activation, so keyboard selection should definitely fire the onclick event regardless of the ultimate decision about when onclick should be triggered.

I'm not sure about this. The active element (document.activeElement) doesn't change when the <select>'s options are changed, if the <select> element is already active. It's not one of the <option>s which becomes the active element; that stays the <select> element. Presumably, that's the case, because <select> supports selecting multiple options too.

If there's no website actually facing this issue, I'm inclined to set severity to S3 and priority to P3.

I'd argue there is no website facing this issue because there is no suitable cross-browser way to trigger an event whenever any select option is chosen. The change event doesn't trigger without a change for obvious reasons, options only trigger click events in Firefox, and different browser's have different behavior for the select click event. I tried to allow duplicate select option selection to trigger an event in https://github.com/ruffle-rs/ruffle/pull/5355#discussion_r715442315, but I couldn't make it work.

This issue has been mentioned other places too:
https://stackoverflow.com/questions/7742739/run-change-event-for-select-even-when-same-option-is-reselected
https://code-examples.net/en/q/982a38
https://code-examples.net/en/q/9a6a71

As for the comment about activeElement, I guess that's why other browsers don't fire click events for options? So why does Firefox? Not that I don't like that Firefox does so (as I said I think that's better), but with that logic surely it should not do so.

If this worked, https://ruffle.rs/demo/ would be using this functionality by adding "Local File" as an option to the dropdown. Because it doesn't is the only reason the local file input has remained visible.

Attached file option click test —

I also added the option click test. It does not fire the click event with accessible methods either.

User-initiated activation triggers include ... pressing the Enter key when an activatable element has focus:

https://w3c.github.io/uievents/#event-flow-activation

I'd argue choosing a select option with a keyboard (which is ultimately done with the Enter key) is an example of element activation

(In reply to danielhunterjacobs from comment #9)

I'd argue there is no website facing this issue because there is no suitable cross-browser way to trigger an event whenever any select option is chosen.

Could be.

The change event doesn't trigger without a change for obvious reasons, options only trigger click events in Firefox, and different browser's have different behavior for the select click event. I tried to allow duplicate select option selection to trigger an event in https://github.com/ruffle-rs/ruffle/pull/5355#discussion_r715442315, but I couldn't make it work.

This issue has been mentioned other places too:
https://stackoverflow.com/questions/7742739/run-change-event-for-select-even-when-same-option-is-reselected

Firing "change" events when the same option is reselected, is a different issue.

https://code-examples.net/en/q/982a38

This refers to a bug from 2007 (https://webbugtrack.blogspot.com/2007/11/bug-280-lack-of-events-for-options.html). More recent issues would give this more weight.

https://code-examples.net/en/q/9a6a71

That seems to be same issue mentioned in above Stackoverflow post.

As for the comment about activeElement, I guess that's why other browsers don't fire click events for options? So why does Firefox? Not that I don't like that Firefox does so (as I said I think that's better), but with that logic surely it should not do so.

Can't answer that question off the top of my head, sorry. This requires deeper analysis.

In the following, I'll limit my work to triaging this.

The spec (https://w3c.github.io/uievents/#event-type-click) specifies:

The click event type MUST be dispatched on the topmost event target indicated by the pointer, when the user presses down and releases the primary pointer button

I couldn't find any clear statement in the spec (https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element) that the <option> element is an event target, but presumably, it is. @annevk: do you know? If so, it'd imply for mouse clicks, Firefox behaves according to the spec.

Flags: needinfo?(annevk)

Firing "change" events when the same option is reselected, is a different issue.

I'm aware, and I don't think that needs a change. What I'm saying is that because of this unfortunate combination of support in different browser implementations, there is no event that can be reliably used to detect when any option is selected.

This refers to a bug from 2007

Ok, but if you test https://bugzilla.mozilla.org/attachment.cgi?id=9274816 in the most recent version of Chrome, you'll see it's still affected. This is a Chrome bug, so it's not what I am asking you to fix though.

That seems to be same issue mentioned in above Stackoverflow post.

Nope, it's the same as this issue; see edit 3 in the link: "Edit 3: I am fully aware of onchange, but the question here is not about onchange if you read carefully. I need to have each selection trigger an event even if they are the same selection (which will not trigger onchange."

I'll leave further analysis to you Firefox devs.

The option element, like all elements, is an event target, but the widget the select element ends up creating isn't necessarily bound by those rules as it's somewhat custom and can also be drawn outside the viewport for instance, depending on the implementation.

It sounds like there are two interoperability issues here:

  1. Should a click event be fired when you select an option of a select element? (And how does that work when it allows for multiple selections?)
  2. Should a change event be fired when you select the same option again?

https://github.com/whatwg/html/issues/1092 covers some of this, but perhaps a new issue specifically for click events is worth filing. danielhunterjacobs, want to do that?

Also strangely enough I could initially reproduce multiple click events in Firefox, but now I can't. Not sure what's going wrong. Note though that if you look at the target of the event, it's not the select element, it's the option element. It arrives at the select element due to bubbling, so you could filter it out in theory.

Flags: needinfo?(annevk)

(In reply to danielhunterjacobs from comment #15)

Firing "change" events when the same option is reselected, is a different issue.

I'm aware, and I don't think that needs a change. What I'm saying is that because of this unfortunate combination of support in different browser implementations, there is no event that can be reliably used to detect when any option is selected.

This refers to a bug from 2007

Ok, but if you test https://bugzilla.mozilla.org/attachment.cgi?id=9274816 in the most recent version of Chrome, you'll see it's still affected. This is a Chrome bug, so it's not what I am asking you to fix though.

That seems to be same issue mentioned in above Stackoverflow post.

Nope, it's the same as this issue; see edit 3 in the link: "Edit 3: I am fully aware of onchange, but the question here is not about onchange if you read carefully. I need to have each selection trigger an event even if they are the same selection (which will not trigger onchange."

Right. Thanks for pointing this out.

I'll leave further analysis to you Firefox devs.

(In reply to Anne (:annevk) from comment #16)

The option element, like all elements, is an event target,

Right, the deduction wasn't obvious. An Element is a Node (https://dom.spec.whatwg.org/#interface-element) which is an EventTarget (https://dom.spec.whatwg.org/#ref-for-eventtarget%E2%91%A1%E2%91%A2).

but the widget the select element ends up creating isn't necessarily bound by those rules as it's somewhat custom and can also be drawn outside the viewport for instance, depending on the implementation.

The spec (https://html.spec.whatwg.org/multipage/form-elements.html#the-option-element) doesn't explicitly mention that.
Interestingly, Chrome's and Firefox's behavior differ here (check with
data:text/html,<select id="sel"><option>one</option><option>two</option><option>three</option><option>one</option><option>two</option><option>three</option><option>one</option><option>two</option><option>three</option>).

It sounds like there are two interoperability issues here:

  1. Should a click event be fired when you select an option of a select element? (And how does that work when it allows for multiple selections?)
  2. Should a change event be fired when you select the same option again?

https://github.com/whatwg/html/issues/1092 covers some of this, but perhaps a new issue specifically for click events is worth filing. danielhunterjacobs, want to do that?

Also strangely enough I could initially reproduce multiple click events in Firefox, but now I can't. Not sure what's going wrong. Note though that if you look at the target of the event, it's not the select element, it's the option element. It arrives at the select element due to bubbling, so you could filter it out in theory.

See Also: → https://github.com/whatwg/html/issues/1092

Presentation is detailed in the Rendering section of the HTML Standard, but it's intentionally somewhat vague.

Let's make this P3/S3 until getting compat issues in specific web apps in the wild.

Severity: -- → S3
OS: Unspecified → All
Priority: -- → P3
Hardware: Unspecified → Desktop
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: