1130656 - http-on-examine-response observer callback not received for file downloads in e10s

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Ian Nartowicz]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20150108202552

Steps to reproduce:

1. Set up an observer for http-on-examine-response
2. Output an alert (alerts service) for each response sent to the observer
3. Load a web page
4. Click on a file link


Actual results:

The loaded page produces masses of notification boxes.  Clicking on the file (torrent file (content type application/x-bittorrent) went direct to the save file dialog.


Expected results:

With autostart.1 turned off (or in pre-e10s versions), the response is received by the observer and can be handled without needing to see the save file dialog.

Comment 1

[Matthias Versen [:Matti]]

related to bug 1113294 ?

Comment 2

[Ian Nartowicz]

More complicated than I first thought :(

I think http-on-examine-response observers are being called after all.  However, they are not called for cached and merged cases, only the respective http-on-examine-cached-response or http-on-examine-merged-response observer.  How long has that been happening and I didn't realise?  So I guess that makes my initial bug report invalid.

Still, I do have a problem.  The nsiURIContentListener that I was debugging appears not to be called under e10s.  Files (eg. a pdf document) don't appear to be sent to my registered listener before the save file dialog appears.

Comment 3

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

Jason, thoughts?

Comment 4

[Jason Duell]

So I don't know the nsURIContentListener stuff at all, but I do know that the only code outside of necko that was changed to divert download channels from the child to the parent was the ExternalHelperApp code (see ExternalHelperAppChild::OnStartRequest() and bug 946239 and bug 975338).  

After ExternalHelperAppChild::OnStartRequest diverts the channel to the parent, no more OnDataAvailable or other channel callbacks happen on the child.  The channel runs on the parent only.  I'm guessing that's the reason nsIURIContentListener isn't called?  But maybe it should be called before the ExternalHelperApp is invoked?  I really don't know the codepath there.  Maybe bz does.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Well, for a start is the nsIURIContentListener registered in the child or the parent?  How is it registered?

Comment 6

[Ian Nartowicz]

I suspect the listener isn't registered at all.  nsIContentHandlers do get called, which implies that the nsIURIContentListener is skipped over.  The only way that seems likely is if a listener just isn't found.

Is bug 940206 (protocol handlers don't get registered) related?

Comment 7

[Boris Zbarsky [:bzbarsky]]

> I suspect the listener isn't registered at all. 

OK, how is it _trying_ to be registered?  I mean, how is Gecko supposed to even know it exists?

Comment 8

[Ian Nartowicz]

Is that a question for me?  I thought it was rhetorical :)

I call registerContentListener() from a javascript component.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Is that a question for me?

Yes.

> I call registerContentListener() from a javascript component.

On the URI loader, right?  In the chrome process or the content process?  I'm guessing chrome process...

On the other hand the content dispatch happens in the child process URILoader.  That's where we look for nsIURIContentListeners.

Comment 10

[Ian Nartowicz]

I see.  So more frame scripts then ...

Should I close this or does someone else want to?  Invalid?  Wontfix?