Issue metadata
Sign in to add a comment
|
The content of SELECT popup is misplaced on style change
Reported by
wowclt...@googlemail.com,
Jul 15
|
||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36 Example URL: http://jsfiddle.net/dJDHd/2702 Steps to reproduce the problem: 1. Navigate to a page with a select/drop down list in an iframe 2. Scroll within the iframe 3. click drop down list What is the expected behavior? All of the options for the select/drop down list should appear. What went wrong? The options list appears to be positioned/rendering relative to the parent window, rather than the iframe (as a guess). This renders options unselectable in the list. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Yes Unsure. Does this work in other browsers? Yes Chrome version: 67.0.3396.99 Channel: stable OS Version: 10.0 Flash Version: We originally witnessed this issue a couple of months ago. We're developing a "canvas" application in SalesForce, which renders as an iframe. All drop downs previously worked, but the past few months we've seen the drop down lists render completely black, unless the user scrolls so the drop down is centered vertically. The referenced JSFiddle replicates the issue by forcing an element to disappear, which chrome will not re-position the drop down list to match the redraw.
,
Jul 16
Thanks for filing the issue! Tried checking the issue on reported chrome version 67.0.3396.99 using Windows 10 with the below mentioned steps. 1. Launched Chrome 2. Navigated to http://jsfiddle.net/dJDHd/2702 3. Clicked on select/drop down menu For the first time when clicked, we have seen "black" colour in the options, yet we were able to select the every item listed. Later when did the same again didn't observe the black colour in dropdown. Attaching the screen cast of the same. @Reporter: Could you please have a look at the screen cast and let us know if anything missed from our end, It would also be helpful if given a confirmation about the issue i.e., getting black colour initially or able/unable to select the items listed. Any further inputs from your end may be helpful in triaging it in a better way.
,
Jul 16
Hi, Thanks for taking a look - that screencast looks exactly right. To clarify, whilst the options are all available to be selected there - there's no limit on how far the black space can get, and so it can fill the drop down list. I've edited the alert that was previously disappearing to have more vertical space in the following JSFiddle, which completely hides all options: http://jsfiddle.net/dJDHd/2830/ Thanks!
,
Jul 16
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 17
Routing to layout team - feel free to move where appropriate.
,
Jul 17
Able to reproduce the issue on reported chrome version 67.0.3396.99 and on the latest canary 69.0.3493.0 using Windows 10 with the new test file provided in comment#3 by reporter. Note: Issue is not seen on Mac 10.13.1 and Ubuntu 14.04 As similar behaviour is seen from M60(60.0.3112.0) considering it as Non-Regression and marking it as Untriaged. Hence removing Needs-Bisect label. Attaching the screen cast of M60 for reference. Thanks!
,
Jul 18
,
Jul 18
Normal bisect result: You are probably looking for a change made after 369953 (known good), but no later than 370117 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/5c174785589ff4d446671eae01bbeb3a045b04c8..deb2b1a6835b09ad4617131a70dab9092a240f31 It's large. We should do per-revision bisect.
,
Jul 18
Per-revision bisect result: You are probably looking for a change made after 370090 (known good), but no later than 370092 (first known bad). CHANGELOG URL: The script might not always return single CL as suspect as some perf builds might get missing due to failure. https://chromium.googlesource.com/chromium/src/+log/431e0ba1472931de155e7540d9ef2385c2e553ca..d82738540a337d7bc4dfb562b8e1034ca99a040a So 4ef7826 "select menu does not refresh when modified dynamically after open" by nolan.robin.cao must be the culprit, and I reviewed it :-O
,
Jul 19
Minimum repro:
<!DOCTYPE html>
<style>.xxx {
height:3em;
}</style>
<select id="sites">
<option></option>
<option>site1</option>
<option>site2</option>
<option>testSite</option>
</select>
<script>
sites.onclick = function() {
sites.classList.add('xxx');
};
</script>
IFRAME isn't needed. It seems something is wrong in RenderWidgetHostViewAura::SetBounds().
,
Jul 19
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f17f0d66e70939a1f84df9774286fa241147a103 commit f17f0d66e70939a1f84df9774286fa241147a103 Author: Kent Tamura <tkent@chromium.org> Date: Thu Jul 19 08:21:45 2018 SELECT popup: Don't move a popup while it is shown on Windows. Windows Aura(?) has a bug on moving a popup window. See crbug.com/863770. This CL reverts a part of crrev.com/370091, and SELECT popups won't be moved to work around the issue. Bug: 137495, 863770 Change-Id: I1d50aa6eb47204b8fe6ea83fddba6966861dff76 Reviewed-on: https://chromium-review.googlesource.com/1143062 Reviewed-by: Keishi Hattori <keishi@chromium.org> Commit-Queue: Kent Tamura <tkent@chromium.org> Cr-Commit-Position: refs/heads/master@{#576416} [modify] https://crrev.com/f17f0d66e70939a1f84df9774286fa241147a103/third_party/WebKit/LayoutTests/fast/forms/select-popup/popup-menu-resize-after-open-expected.txt [modify] https://crrev.com/f17f0d66e70939a1f84df9774286fa241147a103/third_party/WebKit/LayoutTests/fast/forms/select-popup/popup-menu-resize-after-open.html [add] https://crrev.com/f17f0d66e70939a1f84df9774286fa241147a103/third_party/WebKit/LayoutTests/platform/linux/fast/forms/select-popup/popup-menu-resize-after-open-expected.txt [modify] https://crrev.com/f17f0d66e70939a1f84df9774286fa241147a103/third_party/blink/renderer/core/html/forms/resources/listPicker.js
,
Jul 20
I checked in a workaround for M69. We won't move popups on Windows.
,
Jul 23
Verified the fix on Windows-10 using Chrome version #70.0.3500.0 as per the comment#0. Attaching screen cast for reference. Observed that the dropdown was properly shown. Hence, the fix is working as expected. Adding the verified labels. Note: Able to reproduce the issue on chrome version 67.0.3396.99 Thanks...!!
,
Sep 6
Seems to be changed in Chrome version 69. However, this not right. As mentioned above - the drop down isn't being moved. Whilst now technically the user *Should* be able to select a value, but on a page where a lot of elements have been collapsed (Such as using multiple bootstrap accordions), the drop downs can appear outside of bounds. I've attached a screenshot of how it looks (with some data redacted), bear in mind the page in the screenshot resides in an iframe, which can allow the drop down to appear out of visible bounds. Shall I raise this as a different issue? Thanks |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by vamshi.kommuri@chromium.org
, Jul 16