New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 883560 link

Starred by 4 users

Issue metadata

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



Sign in to add a comment

debugger statement not stopping flow

Reported by glen.lit...@gmail.com, Sep 12

Issue description

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

Steps to reproduce the problem:
1. Open attached test HTML file in Chrome with DevTools open
2. Click on <div> as indicated

What is the expected behavior?
The console should show:
  touch

and then stop in the debugger.

What went wrong?
The console shows:
  touch
  touch

and then stops in the debugger.

Did this work before? N/A 

Chrome version: 69.0.3497.92  Channel: stable
OS Version: 6.3
Flash Version:
 
test.html
424 bytes View Download
Please note... must be in "Desktop (touch)" emulation mode.
The same problem happens in incognito mode (no extensions active).
This test works as expected in Firefox (with touch simulation enabled).
The code in the handler function appears to run twice... and only during the second execution is the 'debugger' honored.
On a tablet (real touch), when DevTools is open (not in emulation mode), the same problem happens and "touch" is shown in the console twice before the execution stops on 'debugger'.

When the DevTools is closed, there is no problem and the handler code only runs once.
If the 'debugger' statement removed from the event handler code, the problem does not appear.

If the developer then sets a breakpoint in the handler code, the problem does happen again and the handler code runs twice, only stopping at the breakpoint on the second execution.

So, adding a debugger or a breakpoint in the handler code appears to cause the handler to run twice, only stopping on the second pass.
Tried with and without "Eager evaluation" enabled in the DevTools console and it has no effect on this issue.
So, a workaround, for now, is to NOT put a 'debugger' statement in the event handler routine.  

At least now I can avoid this bug and find other ways to work on the real problem that I was actually trying to solve!
Cc: kkaluri@chromium.org l...@chromium.org
Labels: -Type-Bug -Pri-2 ReleaseBlock-Stable M-69 Target-70 M-70 Target-69 FoundIn-69 OS-Linux OS-Mac Pri-1 Type-Bug-Regression
Owner: einbinder@chromium.org
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on Windows 10, Debian Rodete and Mac 10.13.6 with chrome Stable/Beta #69.0.3497.92, Dev #70.0.3538.16 but not on Canary #71.0.3551.0
Issue is fixed in M71

Regression Range:
==================
Good Build : 71.0.3544.0, #589076
bad  Build : 71.0.3543.0, #588718

For this range per revision bisect script is not launching chrome

Regression Range: 
https://chromium.googlesource.com/chromium/src/+log/71.0.3543.0..71.0.3544.0?pretty=fuller&n=10000

Suspecting 2 CL's which may cause the fix.
https://chromium.googlesource.com/chromium/src/+/085697fefeaee5047b30030016edb95d3bd2bcb7
https://chromium.googlesource.com/chromium/src/+/0e743fb703d753762a8e15ef64c9751090ff3587


Assigning it to the luoe@/einbinder@ to look into this issue and merge the fixed CL in Stable,Beta,Dev


Cc: dgozman@chromium.org pfeldman@chromium.org
Labels: -ReleaseBlock-Stable
Owner: kozy@chromium.org
I bisected this one and it was fixed by https://chromium-review.googlesource.com/c/chromium/src/+/1172234 . I prepared another CL that might fix it on input event side and that is a little smaller and can be merged back: https://chromium-review.googlesource.com/c/chromium/src/+/1241216
Cc: kozyatinskiy@chromium.org
 Issue 891398  has been merged into this issue.

Sign in to add a comment