[e10s] nsIRequest.suspend throws NS_ERROR_NOT_AVAILABLE when running debugger tests with e10s enabled

RESOLVED WONTFIX

Status

defect
RESOLVED WONTFIX
5 years ago
2 months ago

People

(Reporter: ejpbruel, Unassigned)

Tracking

(Depends on 1 bug, Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

No description provided.
Blocks: 1090929
Moving DevTools test bugs to e10s milestone M7 (i.e. not blocking e10s merge to Aurora).
Whiteboard: [e10s-m7]
Blocks: 1103841
The cases in which this occur are pretty small, so depending on the process this is occurring in, it's either the first line of nsHttpChannel::Suspend (parent process) or the first line of HttpChannelChild::Suspend (child process). It looks like they should both have the same semantics - you can't call Suspend before AsyncOpen, and you can't call Suspend after OnStopRequest, except in special cases in the child process.
Summary: nsIRequest.suspend throws NS_ERROR_NOT_AVAILABLE when running debugger tests with e10s enabled → [e10s] nsIRequest.suspend throws NS_ERROR_NOT_AVAILABLE when running debugger tests with e10s enabled
I should look into this at some point in Q1.
Assignee: nobody → ejpbruel
Jason, can you suggest an assignee for this?
Flags: needinfo?(jduell.mcbugs)
jdm's comment 2 is correct: this is almost undoubtedly the result of calling suspend() on a channel that hasn't been opened yet.  NOT_AVAILABLE is a perfectly good response for that.  So I suspect this is a bug in the test code--we need a stack trace here to know anything more.  And only Eddy knows how to get that stack trace from the info here AFAICT.
Flags: needinfo?(jduell.mcbugs) → needinfo?(ejpbruel)
I will look into this and get in touch with Eddy about it.
Assignee: ejpbruel → gkrizsanits
The C++ stack does not say much since the suspend method is called from js (so not much to see other than some xpconnect glue). This is the js code that calls it: http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/webbrowser.js#1484

We get the assertion from HttpChannelChild, that I figured out, and the channel seems to be dead (mState = mozilla::net::PHttpChannel::__Dead)

I think this should be a good starting point for someone from the devtools team who knows this code.

Maybe it's enough just to guard that code against closed requests?

Since I'm not familiar with this code and it does not seem like a platform issue, I pass the ball back to Eddy.
Assignee: gkrizsanits → ejpbruel
Whiteboard: [e10s-m7]
I will be on PTO for the next two weeks, so I won't be able to work on this.
Assignee: ejpbruel → nobody
Flags: needinfo?(ejpbruel)
Note that we should be able to reproduce this bug with the STR in https://bugzilla.mozilla.org/show_bug.cgi?id=1254613#c0
I talked to mayhemer yesterday and he was able to figure out what is going on.

In a nutshell, the call to request.suspend() happens in the child process. request is an instance of HTTPChannel, which lives in the parent thread, so the call to suspend needs to go over IPC. However, at the time onStateChanged is called on nsIWebProgressListener, IPC has not been enabled for HTTPChannel yet, so the IPC request fails.

See bug 1260527 for details. I requested that this bug be given some priority, since this is breaking the devtools, and the console in particular, with e10s.
Depends on: 1260527
Product: Firefox → DevTools

closing as this is a task that no longer seems needed

Status: NEW → RESOLVED
Closed: 2 months ago
tracking-e10s: + → ---
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.