1280616 - Breakpoints not caught on refresh, race condition.

Status: RESOLVED WORKSFORME

(DevTools :: Debugger, defect, P3)

Description

[Greg Tatum [:gregtatum]]

This appears to be a race condition because when a source takes some time to load, this error is reproducible, but when served locally this bug does not happen.

Steps to reproduce:

* Visit: http://gregtatum.com/tmp/breakpoint/breakpoint.html
* Let page load.
* Open debugger.
* Refresh the page.
* The breakpoint is caught.
* Step over once.
* Refresh the page.

Expected Behavior:

* The debugger catches the original debugger statement.
* The step over and debugger buttons function correctly.

Actual Behavior:

* The debugger source is not reloaded
* The currently highlighted line is stuck at the next line, and doesn't go back to the debugger statement.
* The debugger buttons for stepping in and out, etc do not work.
* The reloaded page's content does appear to execute and stop at the breakpoint, but the debugger tool is broken and does not correctly display.

Working Behavior in race condition:

* Download the html and js file from the example, and run locally.
* Repeat the steps to reproduce and observe the expected behavior.

Comment 1

[Greg Tatum [:gregtatum]]

Looks like an error is thrown:

> Handler function DebuggerProgressListener.prototype.onStateChange threw an exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.suspend]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js :: _willNavigate :: line 1943"  data: no]
> Stack: _willNavigate@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js:1943:7
> DebuggerProgressListener.prototype.onStateChange<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webbrowser.js:2536:7
> exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
> @chrome://browser/content/tab-content.js:73:43
> this.E10SUtils.wrapHandlingUserInput@resource:///modules/E10SUtils.jsm:122:7
> @chrome://browser/content/tab-content.js:72:5
> EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:349:5
> ThreadActor<._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:542:5
> ThreadActor<._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:752:7
> ThreadActor<.onDebuggerStatement@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:1828:9
> @http://gregtatum.com/tmp/breakpoint/script.js:2:1
> Line: 1943, column: 0
> 
> 
> navigated; resolution of _defaultNode abortedPromise-backend.js:940

Comment 2

[Eddy Bruel [:ejpbruel]]

I've seen that error before. It's apparently an E10s issue. We have a bug open for it, but I've been unable to find it so far.

Comment 3

[Eddy Bruel [:ejpbruel]]

I consider this a papercut, so I'm marking this as P3.

Comment 4

[Jason Laster [:jlast]]

I wonder if this was fixed. Greg, Honza could you try to reproduce?

Comment 5

[Greg Tatum [:gregtatum]]

Ah, I'm not sure, I don't have that file on my webpage anymore :-/

Comment 6

[:Harald Kirschner :digitarald]

Given all the work around race conditions and breakpoints, closing for now. I have not seen this issue in a while in my stress testing. Lets re-open if we see this happening again.