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

RESOLVED INVALID

Status

()

Core
Networking
RESOLVED INVALID
3 years ago
3 years ago

People

(Reporter: Ian Nartowicz, Unassigned)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
related to bug 1113294 ?
Blocks: 516752
Component: Untriaged → General
(Reporter)

Comment 2

3 years ago
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.
Jason, thoughts?
Component: General → Networking
Flags: needinfo?(jduell.mcbugs)
Product: Firefox → Core
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.
Flags: needinfo?(jduell.mcbugs) → needinfo?(bzbarsky)
Well, for a start is the nsIURIContentListener registered in the child or the parent?  How is it registered?
Flags: needinfo?(bzbarsky)
(Reporter)

Comment 6

3 years ago
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?
> 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?
Flags: needinfo?(mozilla)
(Reporter)

Comment 8

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

I call registerContentListener() from a javascript component.
Flags: needinfo?(mozilla)
> 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.
(Reporter)

Comment 10

3 years ago
I see.  So more frame scripts then ...

Should I close this or does someone else want to?  Invalid?  Wontfix?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.