659251 - Can't access most nsIHttpChannelInternal fields from xpcshell

Status: RESOLVED INVALID

(Core :: XPConnect, defect)

Description

[Jason Duell]

XPCONNECT weirdness.  While trying to fix bug 648878, I've run into an issue where I don't seem to be able to access most nsIHttpChannelInternal methods from xpcshell.  If I run test_traceable_channel_wrap.js (bug 646373 is adding that file), it fails if I wind up running 

(in OnStartRequest:)
  request.QueryInterface(Components.interfaces.nsIHttpChannelInternal);
  addr = request.localAddress;

The QI statement is ok, but I have to comment out the localAddress line for the code to work.  I've also tried replacing it with other nsIHttpChannelInternal calls, and most fail (setPriority, the other localAddr/peerAddr functions).  But setting "request.forceAllowThirdPartyCookie = true" succeeds (as long as I call it before asyncOpen, as it should be).

In the debugger I see HttpChannelChild::OnStartRequest getting called, and it sets the selfAddr/peerAddr fields correctly.  But then the breakpoint I set for GetLocalAddress() never gets hit, and the xpcshell test fails with no good error message.

I also can't get a breakpoint to get hit on SetPriority().  But when I run fennec and break on SetPriority, it gets hits just fine.  So there's something xpcshell-specific about this bug.

I've tried other interfaces--I can QI to nsIHttpChannel and call its methods with no problems.  So also something specific about nsIHttpChannelInternal, it seems...

Any idea appreciated--I'm totally baffled by this.

Comment 1

[Boris Zbarsky [:bzbarsky]]

A few questions:

1)  If you use this code pattern:

  var req2 = request.QueryInterface(Components.interfaces.nsIHttpChannelInternal);
  addr = req2.localAddress

does it work?

2)  Does channelIsForDownload work?  What about 'canceled'?

3)  I assume this is also happening in a debug build, right?  Any interesting warnings there?

Comment 2

[Honza Bambas (:mayhemer)]

Just to note that GetRemoteAddress and such are not implemented in HttpChannelChild.  We have the info in OnStartRequest, we can just finish the implementation of GetAddress etc methods.  Probably lower them to HttpBaseChannel...

Comment 3

[Josh Matthews [:jdm]]

Jason, it sounds like you're being bitten by the bug that callback functions tend to swallow JS errors, like the issue that bug 584793 was trying to work around. I wonder if this is actually erroneous behaviour that should be looked into?

Comment 4

[Honza Bambas (:mayhemer)]

(In reply to comment #2)
> Just to note
Ah, bug 648878...

Comment 5

[Jason Duell]

> It sounds like you're being bitten by the bug that callback functions tend to
> swallow JS errors, like the issue that bug 584793 was trying to work around. I
> wonder if this is actually erroneous behaviour that should be looked into?

Yes, that was it (plus the stubs still existing erroneously in HttpChannelChild.cpp).

I believe the reason the callback functions swallow JS errors is that they are considered things that effectively cancel the channel, but are not fatal. 

Perhaps we should add some code to head_channels that would allow xpcshell tests to easily get a channel wrapper that catches exceptions in OnStart, etc. and barfs.