Closed Bug 417301 Opened 16 years ago Closed 8 years ago

Loading omaha.com results in three file-handling dialogs for blank.gif

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: tasantoro, Unassigned)

References

(
URL
)

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.
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
Actually, the Content-Type sent by the server is "text/plain; charset=UTF-8".
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?
I see.  Apache changed their bug, and we changed our workaround in bug 394647.
Blocks: 394647
Keywords: regression
> 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.
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: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.