Capture for custom events does not follow doc
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox80 | --- | wontfix |
People
(Reporter: tux, Unassigned)
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36
Steps to reproduce:
If I make a custom event, then the capture does not work when usecapture is set to the default value of false, but it does work if it is absent and defaults to false? I made a fiddle to show: https://jsfiddle.net/drogos/3juczq7w/1/
Actual results:
The event listener was not triggered for the event.
Expected results:
The event listener should have triggered for the event.
Comment 1•5 years ago
|
||
I was able to reproduce this issue on latest Nightly version 80.0a1 (2020-07-27) on Ubuntu 18.04, macOS 10.14, and Windows 10. I've attache some evidence for Firefox and Chrome, also I'll change flags accordingly.
Comment 2•5 years ago
|
||
Comment 3•5 years ago
|
||
Comment 4•5 years ago
•
|
||
So which parameter is this bug about? The test case seems to use the 4th param of addEventListener, and that is about allowUntrusted in Firefox.
Usecapture is the 3rd param, and it is always used in the testcase.
https://searchfox.org/mozilla-central/rev/cf561cece0ca9aeaf0202e68699836d957d0c670/dom/webidl/EventTarget.webidl#39-41
You are right! This is not a bug, I am very sorry. It is a user error.
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener
I was checking the parameter list there, and assumed that all the parameters was in order. Looking at the source link you sent revealed that 3rd parameter is 3rd -or- 4th in the doc. Very sorry to have wasted you time on this.
Updated•5 years ago
|
Description
•