558620 - e10s HTTP: finish SetPriority support

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Jason Duell]

This will be one-liner fix, in HttpChannelParent::RecvSetPriority, but first we need to figure out how we'll keep a reference to the chrome nsHttpChannel.

Meanwhile we're simply silently dropping SetPriority requests that happen after AsyncOpen.

Comment 1

[Jason Duell]

Added one-line fix.

http://hg.mozilla.org/projects/electrolysis/rev/e0c179c7e7ae

Comment 2

[Oleg Romashin (:romaxa)]

I'm getting bunch of crashes because mChannel = null and we don't check it for null

Comment 3

[Josh Matthews [:jdm]]

This should only occur if the channel creation fails in RecvAsyncOpen (in which case the call itself should fail, so really a non-issue), or if SetPriority is being called before AsyncOpen.

Comment 4

[Josh Matthews [:jdm]]

Actually, this error doesn't even make any sense.  SendSetPriority is only called in the event that the protocol exists, so the channel should exist.  I think there's some deeper problem here, as mChannel should not be able to be null here.

Comment 5

[Oleg Romashin (:romaxa)]

It is not reproducible on debug builds because everything works very slow there (N900), but it reproducible on normal builds....
Could it be so that async calls are not synced, or something like that? Or should "Cancel" implementation help to close channel properly and prevent calls to bad opened channel...?

Comment 6

[Oleg Romashin (:romaxa)]

Oh, got it...
I'm using sync redirects patch sync version, and it setting mIPCOpen == true in constructor createdByParent == true.
And as result mIPCOpen = true, but HttpChannelParent mChannel == null, and that why we crashing there, we need address this comment to redirects bug