DOMMenuItemActive/Inactive incorrectly dispatched to content
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr91 | --- | unaffected |
firefox94 | --- | unaffected |
firefox95 | --- | unaffected |
firefox96 | --- | wontfix |
firefox97 | --- | wontfix |
People
(Reporter: emilio, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
475 bytes,
text/html
|
Details |
These events should not be exposed to websites.
Reporter | ||
Comment 1•3 years ago
|
||
[Tracking Requested - why for this release]: Unexpectedly web-exposed change.
Comment 2•3 years ago
|
||
I don't think that is the correct regressing bug. I found the last build without that change, and I am still able to reproduce the testcase.
$ mozregression --launch 20211111045525
It looks like ChromeOnlyDispatch is "no" here: https://searchfox.org/mozilla-central/source/layout/generic/nsIFrame.cpp#4394
Trying to investigate how far back that goes, looks like it is pre cvs->hg migration. My hunch is that at some point those were chrome-only events judging by bug 481688.
Reporter | ||
Comment 3•3 years ago
|
||
Ah yeah, sorry, I was going through this code for bug 1744009 and saw the bogus code, and checking out blame pointed to your change. I guess your patch made us dispatch DOMMenuItemInactive
events as well, but you're right that the *Active
ones were already dispatched... Oof, that's quite unfortunate :(
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Set release status flags based on info from the regressing bug 1733263
Updated•3 years ago
|
Comment 5•3 years ago
|
||
Is this something you still want to fix?
Comment 7•3 years ago
|
||
Set release status flags based on info from the regressing bug 1733263
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Description
•