(In reply to Andrea Marchesini [:baku] from comment #10)
I suspect there are several issues here:
We send different Accept header values and the server answers with 2 different images. We must be consistent in how we use the Accept header. I think we have a good solution proposed in comment 7.
The use of content-disposition to generate the file-name.
Reading the code, I see this:
In contentAreaUtils.js we retrieve the content-disposition from the image cache. The content-disposition is used to generate the file name (I guess). But then, the downloading of the image sends different headers then what we sent before - see my previous comment. Nothing guarantees that the server offers the same content when important headers (such as Accept) are sent differently. But more important, nothing guarantees that the server answers always at the same way in general. Maybe the second request contains a different content-disposition value...
I can work on the first part. Gijs, can you check if what I'm saying is correct for this second point? Thanks.
We don't hit the code you referenced because of e10s - there's no document because we're in the parent process. The content type and content disposition have been passed on through messaging before we get there. However, we do not pass that info to nsIWebBrowserPersist (and in fact, off-hand I don't see any relevant parameters where we could do so from the frontend). It's probably determined here: https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/browser/actors/ContextMenuChild.jsm#504-524 but I haven't checked that.
It sounds to me like what you're getting at is that we shouldn't settle on a filename before we make the request and get a response. Unfortunately, that's not how the current code works; nsIWebBrowserPersist needs to know where it's saving things before we invoke it, so we have to prompt for a destination (or default to some "clever" filename guess in $defaultdownloaddirectory) before saving. Reworking all of that is definitely not upliftable, even if it's probably a good idea for the longer term...
Does that answer your question?