Closed
Bug 417301
Opened 17 years ago
Closed 9 years ago
Loading omaha.com results in three file-handling dialogs for blank.gif
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: tasantoro, Unassigned)
References
()
Details
(Keywords: regression)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3) Gecko/2008020514 Firefox/3.0b3 Receive multiple messages regarding inability to open .gif file. Not sure if just an issue with the url listed above or problem with Firefox but it doesn't happen with IE. Example Reproducible: Always Steps to Reproduce: 1. Go to home page on url listed above. 2. 3. Actual Results: Receive three "Opening Blank.Gif" boxes. Expected Results: Firefox would either handle the file or if pop up being blocked handle in the background.
Comment 1•17 years ago
|
||
The site has three of: <iframe id="..." src="neo-images/fills/blank.gif"></iframe> The site incorrectly serves blank.gif with "content-type: text/plain". Firefox sees the combination of text/plain with binary content as indicating that the file is an unknown binary type, and prompts to find out whether you want to download it. The obvious fix is to ask the site to fix its MIME type or stop including blank.gif in this way. But maybe <iframe src> shouldn't trigger a file handling dialog when Firefox can't display the contents. Or do some download sites use <iframe src> to trigger the file handling dialog?
Component: Extension Compatibility → General
Product: Firefox → Core
QA Contact: extension.compatibility → general
Summary: Receive errors on .gif files → Loading omaha.com results in three file-handling dialogs for blank.gif
Version: unspecified → Trunk
Comment 2•17 years ago
|
||
Actually, the Content-Type sent by the server is "text/plain; charset=UTF-8".
Comment 3•17 years ago
|
||
Firefox trunk tries do download http://www.omaha.com/neo-images/fills/blank.gif but Firefox 2 displays it as text ("GIF89a" followed by mostly question marks). What changed in our sniffing?
Comment 4•17 years ago
|
||
I see. Apache changed their bug, and we changed our workaround in bug 394647.
Blocks: 394647
Keywords: regression
Comment 5•17 years ago
|
||
> maybe <iframe src> shouldn't trigger a file handling dialog
For the "sniffing text/plain" case this might make sense. I don't think we can do it in general: sites commonly stick PDF in an iframe (expecting a plug-in to handle it).
And yes, the UTF-8 thing is key.
Comment 6•9 years ago
|
||
This bug is listed the Regression listing - confirm it is working and close: Version 43.0.1 Build ID 20151216175450 User Agent Mozilla/5.0 (Windows NT 5.1; rv:43.0) Gecko/20100101 Firefox/43.0
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•