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.
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.
Component: General → Networking
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?
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?
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.