New issue
Advanced search Search tips

Issue 812260 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Apr 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Changing <option>.innerHTML while its <select> is open closes the <select>

Reported by mfa...@usinternet.com, Feb 14 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36

Steps to reproduce the problem:
1. Attach a CLICK event handler to a SELECT element.
2. Change the innerHTML of one of the OPTION elements within the SELECT
3. Click on the SELECT element in Chrome and the dropdown will appear then disappear immediately.

What is the expected behavior?
The dropdown should remain open.

What went wrong?
The dropdown closed instead of staying open. It remains open on Windows Chrome 64, but closes on OSX Chrome 64.

Did this work before? Yes 59

Does this work in other browsers? Yes

Chrome version: 64.0.3282.167  Channel: stable
OS Version: 10.12
Flash Version:
 
example.html
336 bytes View Download
Summary: Changing <option>.innerHTML while its <select> is open closes the <select> (was: When )
Labels: Needs-Triage-M64
Labels: Needs-Bisect
Components: Blink>Forms>Select

Comment 5 by tkent@chromium.org, Feb 16 2018

Labels: -Needs-Triage-M64
Status: Available (was: Unconfirmed)
Confirmed.

Comment 6 by tkent@chromium.org, Feb 16 2018

Labels: -Needs-Bisect
Owner: tapted@chromium.org
Status: Assigned (was: Available)
Bisect result:

You are probably looking for a change made after 503109 (known good), but no later than 503113 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/37cb780da20a2de49e6af9d27b6065e7901c4ff2..e92361313635c5d5f29ed29b053442c9be8be6ec

"Re-enable listening on private runloop modes, for a whitelist." by tapted@ must be the culprit.

Labels: -Pri-2 hasbisect-per-revision RegressedIn-63 Triaged-ET M-66 Target-65 FoundIn-66 Target-66 FoundIn-64 FoundIn-65 Needs-Triage-M64 Target-64 Pri-1
Able to reproduce the issue on mac 10.12.6 using chrome reported version #64.0.3282.167 and latest canary #66.0.3347.0.
Issue is not seen in OS-Win and OS-Linux.
Bisect Information:
=====================
Good build: 63.0.3220.0
Bad Build : 63.0.3221.0

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/d8336a8510772a57d36fd2f66dbc9c8960ef984c..24ab401b3662d052facf19a169f553ea9a6bf7e1

From the above change log suspecting below change
Change-Id: Idf769c1f830ccb3ddc67205acb9e86aac2ec0460
Reviewed-on: https://chromium-review.googlesource.com/647836

tapted@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Thanks...!!

Comment 8 by tapted@chromium.org, Feb 16 2018

I can take a look... But note this is broken Safari and Firefox. On Safari, the menu stays open, but it shows the old value.

Firefox never changes the value (event.srcElement is undefined). Fixing that gives the same behaviour as Safari.

Old versions of Chrome show the menu twice. Web sites probably shouldn't rely on this behaviour.

tip: change the 'click' to 'mousedown' and this works everywhere \o/.

Comment 9 by tapted@chromium.org, Apr 11 2018

Status: Started (was: Assigned)
https://chromium-review.googlesource.com/c/chromium/src/+/1006238
Project Member

Comment 10 by bugdroid1@chromium.org, Apr 11 2018

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c8568e089e62d4adfc45f1c26dcb7088ffb1db19

commit c8568e089e62d4adfc45f1c26dcb7088ffb1db19
Author: Trent Apted <tapted@chromium.org>
Date: Wed Apr 11 23:07:22 2018

Mac: Return to the old behavior when updating a <select> while inside a click handler.

Blink core reuses the PopupMenu of an element and first invokes Hide() over
IPC if a menu is already showing. Attempting to show a new menu while the
old menu is fading out confuses AppKit, since we're sting in the NESTED
EVENT LOOP of ShowPopupMenu(). Disable pumping of events in the fade
animation of the old menu in this case so that it closes synchronously.

We still want to pump messages in normal/interactive menu fades, otherwise
web content animations / videos will pause for the duration of the AppKit
fade animation. So this only affects explicit calls to PopupMenuHelper::Hide().

r503112 added the logic to unblock animating content on menu fade out, but it
broke a corner case when a <select> menu updates itself in a click handler.

Bug:  812260 
Test: See test case file in bug.
Change-Id: I06a63870126383e44ae2862ebeb133680df2fd8d
Reviewed-on: https://chromium-review.googlesource.com/1006238
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549966}
[modify] https://crrev.com/c8568e089e62d4adfc45f1c26dcb7088ffb1db19/content/browser/frame_host/popup_menu_helper_mac.h
[modify] https://crrev.com/c8568e089e62d4adfc45f1c26dcb7088ffb1db19/content/browser/frame_host/popup_menu_helper_mac.mm
[modify] https://crrev.com/c8568e089e62d4adfc45f1c26dcb7088ffb1db19/content/browser/renderer_host/webmenurunner_mac.mm

Status: Fixed (was: Started)

Comment 12 by tkent@chromium.org, Apr 12 2018

Labels: M-67
Labels: TE-Verified-M67 TE-Verified-67.0.3396.0
Able to reproduce the issue using chrome reported version #64.0.3282.167.

Verified the fix on Mac 10.13.3 using Chrome version #67.0.3396.0 as per the comment #0.
Attaching screen cast for reference.
Observed that dropdown remained open as expected.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!
812260.mp4
190 KB View Download

Sign in to add a comment