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

Issue 668661 link

Starred by 3 users

Issue metadata

Status: Archived
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

'click' events are lost when the debugger is breaking on 'change' events

Project Member Reported by joaodasilva@chromium.org, Nov 25 2016

Issue description

Verified on Linux in both 54.0.2840.100 stable and 56.0.2924.3 unstable.

I have an extension that uses the debugger API.

When I type inside a text <INPUT> field and then click outside of that field, then usually the page sees a 'change' on the input field followed by the 'click' event.

But when the extension invokes DOMDebugger.setEventListenerBreakpoint for 2 eventNames, 'change' and 'click', then the page only sees the 'change' event.

The extension is calling Debugger.resume after the break on the 'change' event. I see the page getting the 'change' event as usual, but the 'click' is gone. I also observe that the debugger "resumed" event comes a bit later.

Sequence of logs:

- break on 'change'
- invoke Debugger.resume()
- page sees 'change'
- ...
- debugger event: resumed

Sequence of logs if the extension only breaks on 'click':

- break on 'click'
- invoke Debugger.resume()
- page sees 'change'
- page sees 'click'

Expected sequence of events with breaking on both 'click' and 'change':

- break on 'change'
- invoke Debugger.resume()
- page sees 'change'
- break on 'click'
- invoke Debugger.resume()
- page sees 'click'
 
Cc: kozyatinskiy@chromium.org
Owner: dgozman@chromium.org
Status: Assigned (was: Untriaged)
The reason is that we still dispatch event loop while on a breakpoint. We mute input events there though, so that might explain what you are observing.

Matching your expectations requires running busy nested loop while on a breakpoint and not dispatching any events. Even if implemented, it would greatly regress the debugging ergonomics while using regular devtools UI. So I'm saying, we are thinking of how this could be resolved, but it is unlikely that we enroll the solution fast.
Status: Archived (was: Assigned)

Sign in to add a comment