New issue
Advanced search Search tips

Issue 765264 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

input onblur="alert(); this.focus()" cannot close popup

Reported by ssen....@gmail.com, Sep 14 2017

Issue description

Chrome Version       : Version 61.0.3163.79 (Official Build) (64-bit)
URLs (if applicable) : https://jsfiddle.net/jeqayyo2/6/
Other browsers tested:
    Firefox 55.0.3 (64-bit): Okayish

What steps will reproduce the problem?

<input onblur="alert('nope'); this.focus()">
<input onblur="alert('nope'); setTimeout(function(i){ i.focus() }, 0 , this)">

Focus one of the inputs then click below them.

What is the expected result?

one popup and after closing it the input is still focused

What happens instead?

The first one results in an unclosable popup
Both:
When repeatedly pressing Esc then with mouse below input results in unresponsive inputs after a few rounds. 
Which even persist on a reload with the reload-arrow. 
Pressing enter in the address bar fixes it.

 

Comment 1 by woxxom@gmail.com, Sep 14 2017

Attaching a test html for the repro.
1. open the html file
2. click inside the text area
3. click outside the text area
4. close the popup dialog
Expected: the popup is closed
Observed: the popup is re-opened

Bisect info: 412947 (good) - 412953 (bad)
https://chromium.googlesource.com/chromium/src/+log/1cfa4f01..ab5732d3?pretty=fuller
Suspecting r412949 "Check Content Window Visibility in DesktopNativeWidgetAura::IsVisible"
Landed in 54.0.2833.0

Confirmed r412949 by NOP'ing the added "content_window_->IsVisible()" check
in DesktopNativeWidgetAura::IsVisible() and observing the bug is gone.

test.html
171 bytes View Download
Labels: Needs-Triage-M61
Cc: pnangunoori@chromium.org
Labels: -Type-Bug hasbisect-per-revision OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Owner: robliao@chromium.org
Status: Assigned (was: Unconfirmed)
Tested on latest Chrome Stable #661.0.3163.91,  Canary # 63.0.3218.0 on Windows 7, Mac 10.12.6 and Ubuntu 14.04 and able to reproduce the issue.

Using the per-revision bisect providing the bisect results,
Good build: 54.0.2832.0 (412743)
Bad build: 54.0.2833.0 (413134 )

You are probably looking for a change made after 412948 (known good), but no later than 412949 (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/e339d7ccee8a30818ed8d7c511ca0df01b8342c3..cbaec91aacdd72f3f2941ff3f7b7706100d5081e

From the CL above, assigning the issue to the owner concerned.

@robliao: Looks like an intended change. Could you please confirm whether it is an issue or working as expected?

Review-URL: https://codereview.chromium.org/2256983003


I have the same issue with cold fusion forms. The onFocus and onBlur both cause the pop up to return when selecting ok and not disappear. Since the AF is going to Chrome in the near future I have to make sure all the JQuery and JavaScript settings work in an onBlur or onFocus situation in Chrome.
Labels: Proj-MacViews
Having the same issue.
Using version 66.0.3359.139 64 bits on Windows 10.
The option to "Prevent this page from creating additional dialogs" is not available anymore locking user in infinite loop of alert messages.
Error had already been reported before on  issue 666205  but was marked "Wontfix".
At some point the Chrome team decided to remove the "Prevent this page from creating additional dialogs" option and after reported as a problem on  issue 721138  the chrome team decided it is expected behavior on Chrome.
Right now Chrome is causing lots of problem on applications that were working. Javascript hasn't changed, HTML hasn't changed, Chrome did and somehow it's team think everyone else has to adapt. 
I hope you see the irony, you put yourself in this situation, now fix it.
Labels: Group-Focus_Input_Selection_Activation_KeyState

Sign in to add a comment