User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:22.214.171.124) Gecko/20100401 Firefox/3.6.3 Build Identifier: 20100428015153 When a streamconverter for mimetype "application/epub+zip" is registered, it is not called when a file with this mimetype is downloaded from a website. This worked without problems in Fennec 1.0. Please check the attached testcase xpi which is a stripped down version of my add-on. As this breaks one of the main functions of my add-on, this is a very serious problem for me. Reproducible: Always Steps to Reproduce: 1. Install the attached testcase xpi 2. Open this URL: http://www.epubbooks.com/book/247/melville-moby-dick.epub Actual Results: Dialog "What would you like to do with melville-moby-dick.epub?" is displayed. Expected Results: No dialog is displayed. File is downloaded, when finished the text "test" is displayed. In the console "start" and "stop" is displayed, when the streamconverter starts and stops his work.
This is the buildid of the last version which still worked: 20100412024516 This is the id of the first version which failed: 20100413022254
This was a purposeful change: stream converters are not longer applied to responses that have "Content-Disposition: attachment" set on them. The link in comment 0 has such a setting. For what it's worth, the attached test addon has exactly the security hole the change was meant to prevent.
Okay, I understand. My add-on is an ePub-reader for which it's essential to get especially responses with "Content-Disposition: attachment". Is there any other way to get the data?
> Is there any other way to get the data? Yes. You could sort of cheat and register an nsIContentSniffer contract in the "net-content-sniffers" category. Then in your getMIMETypeFromContent you could remove the Content-Disposition header so that your stream converter gets called. But you need to be _very_ careful if you do this, if you're generating HTML from the result. In particular, you need to make sure that any part of that HTML that's under control of the original data can't possibly be used to trigger script (so anchor hrefs are out, as are <script> tags, on* handlers, etc etc). If you're sure you always generate HTML that could be the output of an HTML sanitizer, you _might_ be ok.
And in particular, the point is that "attachment" really is supposed to mean "don't show this inline, period". Are ePub documents really commonly served that way? Have you considered complaining to the people doing the serving, if so?
Thanks for your hints!
verified FIXED on build: Mozilla/5.0 (X11; U; Linux armv7l; Nokia N900; en-US; rv:126.96.36.199pre) Gecko/20100430 Namoroka/3.6.5pre Fennec/1.1b2pre