How to debug image not loading intermittently exclusively on Firefox?
The image (GIF67) is being generated and sent via binary stream from the server (using secure connection), Explorer and Chrome always display the image, Firefox intermittently fails to load it with no distinct success-fail pattern.
I have verified that this is a Firefox issue, by analyzing the tcp packages and confirmed that the response from the server is always the same at bytes level either on the success as the fail scenario.
How could I setup Firefox to log the render process of the image requested?
Actions taken:
-Tested with Firefox versions from 10 to 28, fails -Tested with Chrome and IE, image always renders correctly -Followed: https://support.mozilla.org/en-US/kb/firefox-cant-load-websites-other-browsers-can?esab=a&as=aaq https://support.mozilla.org/en-US/kb/fix-problems-images-not-show?esab=a&as=aaq -Modified Chrome and IE request headers to mimic the Firefox request, image renders correctly -Modified Firefox headers to mimic Chrome request, fails -Analyzed tcp packages, response is the same for fail and successful render -Reconstructed the image correctly by recovering the tcp packages from the requests of a successful rendering as well as for a bad rendering.
Sometimes it is possible to make 50 requests and see the image being displayed correctly, some other times you could make 50 requests and not see the image displayed, but mostly it is possible to load the image 20 times and have 1 fail.
Thanks in advance!
Chosen solution
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?
Read this answer in context 👍 0All Replies (9)
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
Modified
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.
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.
Seçilmiş Həll
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?
Modified
Well I certainly learned something from this thread! I found this after you found the issue: MDN: Content Negotiation
Modified