Select flickers with color overrides / HCM if there's a transition; seizure risk
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
People
(Reporter: erwinm, Assigned: emilio)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(3 files)
914.44 KB,
video/quicktime
|
Details | |
183 bytes,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:88.0) Gecko/20100101 Firefox/88.0
Steps to reproduce:
(forked from bug 1694064.)
In Firefox:
about:preferences.
Search for "Color."
And set override to "Always."
Click "Edit Bug" here.
Click on the "Platform" menu and try to select a platform.
Actual results:
The menu strobes.
Expected results:
It shouldn't strobe, and should let users select a platform.
The strobing goes away if I set override to "Never."
This does not go away if I use Mozregression and test on an older version which uses user colors instead of high-contrast mode.
This does go away in Troubleshoot mode, but, well Troubleshoot mode cuts a lot of other strobe-blocking fixes.
This doesn't go away if I comment out my font size css, so that's not it.
This doesn't go away if I disable all extensions, and for safety reasons, I usually need to enable most of them.
Mozregression failed, but the reression is somewhere in here:
Comment 1•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
The regression coincides with Firefox 68. https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/68
I turned off all extensions again, re-enabled them a few at a time, and it appeared to be an incompatibility with No Transition... https://addons.mozilla.org/en-US/firefox/addon/no-transition/
Then turned my safety css back on and there's an incompatibility with that too.
It hurts.
It appears to come from the following in userContent.css:
*{transition-duration:1ms !important; animation-duration: 1ms !important; }
How are web users supposed to protect ourselves from web sites...?
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Ok, I can repro on mac and Linux if I force colors on a page like the attached one. It seems like a bad interaction with this event listener, most likely:
transition-duration: 1ms !important
causes transitions for every property, which seems fairly unfortunate, it's really inefficient.
Assignee | ||
Comment 5•3 years ago
•
|
||
.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 6•3 years ago
|
||
Options can change styles for a variety of reasons and we don't want
transitions on them to re-update the whole menulist.
Updated•3 years ago
|
Comment 8•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Please nominate this for ESR91 approval when you get a chance.
Assignee | ||
Comment 10•3 years ago
|
||
Comment on attachment 9233939 [details]
Bug 1720050 - Ensure to listen to transition events on <select>, not bubbled events from options. r=Gijs
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: With some combinations of rules, select elements could flicker badly.
- User impact if declined: see above
- Fix Landed on Version: 92
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Relatively simple patch affecting transition handling in <select>.
- String or UUID changes made by this patch: none
Comment 11•3 years ago
|
||
Comment on attachment 9233939 [details]
Bug 1720050 - Ensure to listen to transition events on <select>, not bubbled events from options. r=Gijs
Approved for 91.1esr.
Comment 12•3 years ago
|
||
bugherder uplift |
Description
•