Issue metadata
Sign in to add a comment
|
Setting an element attribute while menu is open causes <select>'s dropdown menu to close and reopen |
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.102 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Apply a CSS style that includes the `transition` property to a <select> 2. Click the <select> to open it. What is the expected behavior? The <select>'s native dropdown menu should be displayed. What went wrong? The native dropdown menu is displayed (with associated native animation), but then abruptly disappears and is then displayed again, resulting in an unsightly flicker/flash/blink of the menu. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Chrome 49 presumably Does this work in other browsers? Yes Chrome version: 50.0.2661.102 Channel: stable OS Version: OS X 10.11.5 Flash Version: Shockwave Flash 21.0 r0 See https://github.com/twbs/bootstrap/issues/19865 for some more details and several confirmations from users. So far this has only been observed on Mac OS X. Removing the CSS `transition` style also removes the unwanted flicker. Unfortunately, nobody's been able to craft a reduced testcase so far. It's possible that this issue is related to issue 613885 .
,
May 26 2016
,
May 31 2016
Another video of this bug in action: https://youtu.be/vtYLUXB0gEc Chrome version: Version 51.0.2704.63 (64-bit) (stable) OSX version: 10.11.5 (15F34)
,
May 31 2016
I have managed to isolate and reproduce the problem: https://jsfiddle.net/fczbkk/jhdsua5k/ The SELECT element is redrawn when its attributes change. Even if these attributes have no impact on element's visual.
,
May 31 2016
fczbkk@ I'm not sure that your attribute bug is related. Your testcase didn't repro for me until I updated to Chrome 51 from Chrome 50. Whereas the transition bug was reported by several folks who were using Chrome 50.
,
May 31 2016
@fczbkk I couldn't replicate the bug with your test case. I'm on v50.0.2661.102.
,
May 31 2016
@cvrebert I understand. So should I create new issue for that?
,
May 31 2016
@fczbkk Absolutely.
,
May 31 2016
It has nothing to do with CSS transitions. Can reproduce on 52.0.2743.6 / Mac / Retina. Given comment 5, requesting bisect to see if this broke in Chrome 51.
,
May 31 2016
Filed a new issue for the problem I encountered: https://bugs.chromium.org/p/chromium/issues/detail?id=616197
,
Jun 1 2016
==================================== Good Build: 51.0.2704.0 Base Position: 385938 Bad Build: 51.0.2704.63 Base Position: 370090 ===================================== Able to repro this issue on MAC (10.11.5) for the Google Chrome Stable Version - 51.0.2704.63 This is a regression issue broken in M51, below mentioned is the bisect info: CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/51.0.2704.0..51.0.2704.63?pretty=fuller&n=10000 Suspecting Commit: 7ce0183043107443e995b20de48fdc6bf4381821 Review URL: https://codereview.chromium.org/1983903002 @spqchan: Could you please look into the issue, and if it has nothing to do with your changes and if possible please do assign it to the concerned owner. Thank you. Note: Issue observed only on MAC OS. From M52 first build issue is not reproducible.
,
Jun 1 2016
I suspect this commit actually: https://chromium.googlesource.com/chromium/src/+/b752c263dea6d780e5814be537f4a18732ac5409
,
Jun 1 2016
Agree with #12. Unless it's related to the fullscreen UI, my commit shouldn't affect it
,
Jun 1 2016
This was already fixed. |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by cvrebert@google.com
, May 25 2016