User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140410150427 Steps to reproduce: 1. Start the attached xulrunner app. This app's main page contains the following JS code: console.log("1"); console.log("2"); Components.utils.import('resource://gre/modules/devtools/dbg-server.jsm'); DebuggerServer.chromeWindowType = null; if (!DebuggerServer.initialized) { DebuggerServer.init(); DebuggerServer.addBrowserActors(null); } DebuggerServer.openListener(6000); console.log("3"); function test() { console.log("test/1"); console.log("test/2"); } 2. Use firefox's developer tools to connect to it (localhost:6000). 3. In the remote devtools UI, set a breakpoint in global JS scope, e.g. on line 'console.log("1");'. 4. Reload the page by evaluate 'location.reload()' in the web console. The breakpoint may be hit, if so, continue and reload the page again. Actual results: If reload the pages several times, breakpoints in global scope can't be triggerd any more, even if you remove and reset the breakpoints. Sometimes closing the remote devtools, and reconnecting to the xulrunner app may help, but sometimes not work. Expected results: Breakpoints in global scope always be triggerd during a reload.

I test with Firefox 29b7, as well as 30.0a2 (2014-04-16), run as both debugger and debugee. Both version have this issue. Sometimes, location.reload() even tiggers exceptions, such as(taken from 30.0a2): error occurred while processing 'evaluateJS: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [xpcIJSWeakReference.get]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/webconsole.js :: WCA__getWindowForBrowserConsole :: line 171" data: no]Line: 171, column: 0 Or this exception: error occurred while processing 'prototypeAndProperties: TypeError: aRawObj.location is null Stack: DOMNode@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:3783:7 ObjectActor.prototype.grip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2932:1 ThreadActor.prototype.objectGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:2025:5 ThreadActor.prototype.createValueGrip@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:1978:9 ObjectActor.prototype._propertyDescriptor@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:3239:7 ObjectActor.prototype.onPrototypeAndProperties@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:3027:7 DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1103:9 DT__processIncoming/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/server/transport.js:201:9 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:80:7 EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:387:5 ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:554:5 ThreadActor.prototype.onInterrupt@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:1713:7 DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js:1103:9 DT__processIncoming/<@resource://gre/modules/devtools/dbg-client.jsm -> resource://gre/modules/devtools/server/transport.js:201:9 makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/DevToolsUtils.js:80:7 EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:387:5 ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:554:5 ThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:837:7 BreakpointActor.prototype.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/server/main.js -> resource://gre/modules/devtools/server/actors/script.js:4283:5 @chrome://remotedebug/content/remotedebug.html:7:3 Line: 3783, column: 6

This is a known limitation of the GC-sensitive behavior of some debugger APIs, see bug 944261. In short, don't expect scripts that don't hang around long enough, to always trigger breakpoints. Your example code is such a case: the top-level script gets executed and then GCed, since the engine can determine that there is no way for it to run again (e.g. no event handlers defined). Breakpoints in more realistic code should always work however.

Thank you for explaination. However, even if I register event handlers, breakpoints in event handler can't survive after a reload. For example: function testFunc() { console.log("testFunc/1"); //set breakpoint here console.log("testFunc/2"); } onload = testFunc; document.onclick = testFunc; Set the breakpoint and reload, the breakpoint won't be triggered during 'load' event or by clicking the page. We must reset the breakpoint so that it is triggered by clicking. PS, I note that 'debugger' statement in JS is triggered reliably, so it may be used as a workaround sometimes.

Panos, I can't reach you on irc right now, so might as well ask in the bug instead. Isn't the problem with comment 3 that when you reload the page, you get a new instance of testFunc, so the breakpoint you set on the previous instance won't trigger?

The server keeps a breakpoint store that maps breakpoints to source locations. Since the source doesn't change after a reload, the server should still try to set the breakpoint again at the same source location. The onload case might be fixed by bug 1054159, but I can't think of any reason why the onclick breakpoint wouldn't trigger.