Vineg Reporter
	Description • 8 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.107 Safari/537.36

Steps to reproduce:

Open web console (ctrl+shift+I), open debugger tab, place a breakpoint anywhere in JS code, reload page so script execution paused on breakpoint, type 1+1 in console, press enter


Actual results:

no output in console. if I reload page, web console still not responsive to user input


Expected results:

expected console output "2".

	Loic
	Comment 1 • 8 years ago

I can't reproducie it in FF46 on Win 7 with e10s on/off.

Could you test with a fresh profile, please:
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

	Vineg Reporter
	Comment 2 • 8 years ago

edit: when paused in debugger reload the page few times(ctrl+R), debugger still paused. Console hangs almost every time, some times it starts working after pressing F8 to resume script execution.

I tested with fresh profile on google.com.

	Loic
	Comment 3 • 8 years ago

Ok, I'm able to reproduce it with e10s enabled. The crucial step is reloading the page a few times before using the console.

It works normally with e10s disabled.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 4 • 8 years ago

Jeff, just wanted to flag this for the devtools team, sounds bad

	J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)
	Comment 5 • 8 years ago

Jeff is out, over to :bgrins for triage.

	Brian Grinstead [:bgrins] Assignee
	Comment 6 • 8 years ago

Seeing this error:

error occurred while processing 'autocomplete: Error: Debugger.Frame is not live
Stack: WCA_onAutocomplete@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:935:9
DSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5
EventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:349:5
ThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:543:5
ThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:752:7
BreakpointActor<.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/breakpoint.js:153:12

	Brian Grinstead [:bgrins] Assignee
	Comment 7 • 8 years ago

Test case:

Open page
Open debugger and set breakpoint on line 3 of the html page
Reload page twice
Evaluate 1+1 in console

Expected:
console outputs 2

Actual:
console doesn't output anything

	Brian Grinstead [:bgrins] Assignee
	Comment 8 • 8 years ago

Better stack trace:

"onPacket threw an exception: Error: Server did not specify an actor, dropping packet: {"error":"unknownError","message":"error occurred while processing 'autocomplete: Error: Debugger.Frame is not live\nStack: WCA_onAutocomplete@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/webconsole.js:935:9\nDSC_onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1643:15\nChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5\nEventLoop.prototype.enter@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:349:5\nThreadActor.prototype._pushThreadPause@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:543:5\nThreadActor.prototype._pauseAndRespond@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/script.js:752:7\nBreakpointActor<.hit@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/actors/breakpoint.js:153:12\n@http://localhost/testapp/breakpoint.html:3:5\nLine: 935, column: 9"}
Stack: DebuggerClient.prototype.onPacket@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/client/main.js:939:9
LocalDebuggerTransport.prototype.send/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:569:11
exports.makeInfallible/<@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:101:14
DevToolsUtils.executeSoon*executeSoon@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/DevToolsUtils.js:34:11
LocalDebuggerTransport.prototype.send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:562:7
DSC_send@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/server/main.js:1391:5
ChildDebuggerTransport.prototype.receiveMessage@resource://gre/modules/commonjs/toolkit/loader.js -> resource://devtools/shared/transport/transport.js:742:5
Line: 939, column: 9"

	Brian Grinstead [:bgrins] Assignee
	Comment 9 • 8 years ago

Also bad: once this happens and then you close the toolbox, you are unable to reopen it

	Jeff Griffiths (:canuckistani) (:⚡︎)
	Comment 10 • 8 years ago

cc;ing Bryan and adding P1.

	Brian Grinstead [:bgrins] Assignee
	Comment 11 • 8 years ago

So.. I've even been able to get breakpoints to fail on this test page in e10s and also have the source occasionally not show up - I filed Bug 1246299 for that.  I'm not sure if it's strictly blocking but tagging it so we can track that work.

It seems the webconsole is getting confused with what frameActor is active, so that needs to be fixed.  I think we could make this fail more gracefully relatively easily so that could be a first step.

	Brian Grinstead [:bgrins] Assignee
	Comment 12 • 8 years ago

More graceful failure at least if we get in this bad case.  This allows the tools to still function if this case is hit (and the toolbox can close/reopen successfully)

	Brian Grinstead [:bgrins] Assignee
	Comment 13 • 8 years ago

Comment on attachment 8716514 [details] [diff] [review]
webconsole-frame-actor.patch

See comment 12

	James Long (:jlongster)
	Comment 14 • 8 years ago

Comment on attachment 8716514 [details] [diff] [review]
webconsole-frame-actor.patch

Review of attachment 8716514 [details] [diff] [review]:
-----------------------------------------------------------------

How come you remove the `if(frameActor)`? You just want it to be caught in the exception handler now?

Looks fine to me

	Brian Grinstead [:bgrins] Assignee
	Comment 15 • 8 years ago

https://treeherder.mozilla.org/#/jobs?repo=try&revision=932a86d8f531&selectedJob=17770061

	Brian Grinstead [:bgrins] Assignee
	Comment 16 • 8 years ago

(In reply to James Long (:jlongster) from comment #14)
> How come you remove the `if(frameActor)`? You just want it to be caught in
> the exception handler now?

Yeah, if there's a frameActorId but no associated frameActor I think that's also an exceptional case

	Pulsebot
	Comment 17 • 8 years ago

https://hg.mozilla.org/integration/fx-team/rev/97e1bc41a847

	Carsten Book [:Tomcat]
	Comment 18 • 8 years ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/97e1bc41a847

	Jim Mathies [:jimm]
	Comment 19 • 8 years ago

Brian, we might roll e10s out to a subset of users in 47. Would you like to uplift this?

	Brian Grinstead [:bgrins] Assignee
	Comment 20 • 8 years ago

(In reply to Jim Mathies [:jimm] from comment #19)
> Brian, we might roll e10s out to a subset of users in 47. Would you like to
> uplift this?

Yeah this should be safe to uplift, I'll create a request

	Brian Grinstead [:bgrins] Assignee
	Comment 21 • 8 years ago

Comment on attachment 8716514 [details] [diff] [review]
webconsole-frame-actor.patch

Approval Request Comment
[Feature/regressing bug #]: e10s (no particular regressing bug, the debugger / webconsole seem to have always had this problem in e10s)
[User impact if declined]: In e10s, the web console becomes unusable when reloading a page multiple times with a breakpoint that gets hit during load.  Then when you close the toolbox, you aren't able to re-open it.  Note that this patch doesn't fully fix the problem, it's just making the failure less bad.  Trying to evaluate scripts while paused in this condition will still fail, but it will begin working again when continuing.  And the toolbox can be closed and re-opened with no problems.
[Describe test coverage new/current, TreeHerder]: none
[Risks and why]: The patch itself is adding a try/catch in a place that shouldn't throw an exception, so it's pretty low risk.  Again, it's not a full fix for the problem though, it's just making things less bad.

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 22 • 8 years ago

Hello Vineg, could you please verify this issue is fixed as expected on a latest Nightly build? Thanks!

	Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)
	Comment 23 • 8 years ago

Comment on attachment 8716514 [details] [diff] [review]
webconsole-frame-actor.patch

Minimizing the likelihood in which webconsole becomes unusable in e10s. Beta47+

	Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)
	Comment 24 • 8 years ago
bugherder uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/c37d4988403d

	Kazi Nuzhat Tasnem
	Comment 25 • 8 years ago

I have reproduced this bug with Firefox nightly 46.0a1(build id:20160119030232)on
windows 7(64 bit)

I have verified this bug as fixed with Firefox beta 48.0b3(build id:20160623122823)
User Agent:Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
 
[bugday-20160727]