Hey, So you mentioned that it is only for one image, does this also happen for an image with the same (gif67) type? Please also make sure Firefox is up to date and if it continues to happen in the latest version please see below :-)

-Modified Chrome and IE request headers to mimic the Firefox request, image renders correctly

Where? You modified the packet from the server? or the response given to Firefox and rendered it in another browser

Analyzed tcp packages, response is the same for fail and successful render

Please give an example.

1 out of 20 times it fails, do you know if this is consistent on a different network or computer? Also, the format of the gif what kind of encoding? With this information and some good steps to consistently reproduce a bug in [bugzilla.mozilla.org] will help us investigate this as well.

Thank you

Hi,

Hey, So you mentioned that it is only for one image, does this also happen for an image with the same (gif67) type? Please also make sure Firefox is up to date and if it continues to happen in the latest version please see below :-)

This is the only image (so far) that I have detected, firefox is up to date, this has been reproduced using at least Firefox 28 (latest) and Firefox 10 on different machines.

-Modified Chrome and IE request headers to mimic the Firefox request, image renders correctly Where? You modified the packet from the server? or the response given to Firefox and rendered it in another browser

I modified the headers being sent on the request from the browser using HttpHeaders modifier Plugins on the browser, so, from chrome I've modified the headers o be the same of those sent by Firefox and Chrome always renders the image correclty, also I have modified the request headers sent by Firefox to be the same as chrome and the image has failed to be displayed.

Analyzed tcp packages, response is the same for fail and successful render Please give an example.

Using Wireshark I captured the tcp packages being sent and received while requesting the image and displaying it right as well as requesting the image and having it fail to render. The packages were extracted and the binary data representing the GIF of each response (good/bad) was analyzed, it was found that the data being transferred was exactly the same, (exporting the Hex representation and using diff/compare) except for 3-4 fields on the response headers (time, Universal Id, count..)

1 out of 20 times it fails, do you know if this is consistent on a different network or computer? Also, the format of the gif what kind of encoding?

It has been verified to be consistent on different networks, computers and Firefox versions, the format is GIF87a (previously I said 67, sorry, that doesn't even exists).

With this information and some good steps to consistently reproduce a bug in [bugzilla.mozilla.org] will help us investigate this as well.

Sadly, I am currently not able to reproduce the behavior in a different system or using a different resource. This leads me to think that the system/product is the issue, however given the previous tests, my best option is to try debugging Firefox, I have read about debugging, however it is either for crash or at http data transfer level which is not helping, is there any other way to analyze the process of rendering the image on Ff?

Thank you very much for your very valuable time.

Not a problem. What is strange is that is sounds like the server is treating a request from Firefox differently, but if they are the same request from another browser, why would it return the bad version of the gif file?

Another theory is that there is a stored request on the proxy or local router that is seeing the same request from before and immediately giving you the same response. In this case flushing the dnscache may be helpful, but I do not know what OS you are running.

Another theory is malware in an addon injecting the packets coming back? Most likely not though since you are modifiying the headers? Unless they are modified past the addon request? No, maybe?

The server treating the requests differently from Firefox was my first thought, and because of that I changed the headers with the same result.

As of the Addons, the problem was reproduced with several clean installations of Firefox, with no addons and even on safe-mode, so I would say that the addons might not be related.

Regarding the proxy or local router, that might be involved, however there's the wireshark capture indicating that both, the good image as the bad one, came in identical packages.

I will redo that tcp traces test to triple check that the server is responding with the same data for any request on any browser and check if we have something like the proxy/local router caching.

Is there a way to set the debug level of firefox to log everything that is possible to it?

Thanks again.

Does this request to the server always has the same URL?

If this is the case then you can try to append some random code via a get parameter (?xxxx) to get a unique URL and prevent Firefox from using a cached image instead of a new image from the server.

See also:

• https://developer.mozilla.org/en/The_Necko_HTTP_module
• https://developer.mozilla.org/en/HTTP_Logging

Hi,

Does this request to the server always has the same URL? Yes.

If this is the case then you can try to append some random code via a get parameter (?xxxx) to get a unique URL and prevent Firefox from using a cached image instead of a new image from the server.

I did as suggested having the same faulty result for any request (using different extra param), at the same time I can see a successful rendering from Chrome and Explorer.

I have verified using Wireshark from handshake to end of session each tcp package and there is no reset, timing out, extra ACK, or anything that indicates to me that there might be an HTTP/TCP problem. Since the HTTP links you sent are modules of Firefox it might give me some other information, I will definitely check them out.

I am also inclining on checking out the decoders used on Firefox vs that used on Chrome/Explorer given that so far I believe the response is the same for any request from any browser.

Would you know which is the GIF(or image) decoder used in Firefox and if there's a way to debug it?

It's awesome to have Top Contributors helping out, thank you very much in advance.

PD: I clicked "Not helpful" accidentally on one of the responses, I apologize, each of them have been extremely helpful.

The mime type was wrong: "Image/png".

I'm currently ashamed as this was the second thing to check on my list and somehow I missed it.

I've simulated an stressed server by creating a Web Service to send the image via streaming and sleeping the thread after flushing a small amount of data, I was able to reproduce the problem (Chrome and Explorer renders image fine and Firefox fails) and I was also able to see it fixed by setting the right mime type (don't you say?).

This surely is not a bug, but I find it interesting that Chrome and Explorer are both able to accept that data and show the Gif while Firefox gives up on the stream if it takes a few milliseconds after receiving a package and the gif mime type is not properly set.

Thank you very much for the people who helped me through.

PD: Would anyone know the concrete reason for Firefox to have this behavior differently than Chrome/Explorer at stream/encoder level?

Well I certainly learned something from this thread! I found this after you found the issue: MDN: Content Negotiation