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

Status: RESOLVED WONTFIX

(DevTools :: Debugger, defect)

Comment 1

[Chris Peterson [:cpeterson]]

Moving DevTools test bugs to e10s milestone M7 (i.e. not blocking e10s merge to Aurora).

Comment 2

[Josh Matthews [:jdm]]

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.

Comment 3

[Eddy Bruel [:ejpbruel]]

I should look into this at some point in Q1.

Comment 4

[Brad Lassey [:blassey] (use needinfo?)]

Jason, can you suggest an assignee for this?

Comment 5

[Jason Duell]

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.

Comment 6

[Gabor Krizsanits (INACTIVE)]

I will look into this and get in touch with Eddy about it.

Comment 7

[Gabor Krizsanits (INACTIVE)]

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.

Comment 8

[Eddy Bruel [:ejpbruel]]

I will be on PTO for the next two weeks, so I won't be able to work on this.

Comment 9

[Eddy Bruel [: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

Comment 10

[Eddy Bruel [:ejpbruel]]

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.

Comment 11

[Jason Laster [:jlast]]

closing as this is a task that no longer seems needed