Closed
Bug 83241
Opened 24 years ago
Closed 24 years ago
file:// needs decoder to sniff file types
Categories
(Core :: Networking: File, defect, P2)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: mscott, Assigned: mscott)
References
Details
(Keywords: testcase, Whiteboard: [PDT+]Have fix sr=rpotts)
Attachments
(1 file)
3.11 KB,
patch
|
Details | Diff | Splinter Review |
Currently if you attempt to load an image in a file that doesn't have an
extension, 6.x throws the unknown content handler.
i.e. if I have a .jpg in a local file called "test". We won't display the image.
If the file looks like "test.jpg" we do show the image.
Both 4.x and IE properly render the image when the file is called "test".
I believe our unknown decoder should be smart enough to not only sniff for
content types like html but to also sniff for some basic image content types.
Assignee | ||
Comment 1•24 years ago
|
||
setting up for .9.2. The change should be pretty straightforward. This bug came
from some guys at Sun where this is becoming a corporate escalation for them.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 2•24 years ago
|
||
Comment 3•24 years ago
|
||
sr=rpotts
Looks good to me...
Assignee | ||
Updated•24 years ago
|
Whiteboard: Have fix sr=rpotts
Comment 4•24 years ago
|
||
adding PDT+. Please check into the trunk as soon as possible.
Whiteboard: Have fix sr=rpotts → [PDT+]Have fix sr=rpotts
Comment 6•24 years ago
|
||
Is this over HTTP? Over HTTP, if there is a Content-Type, then we should never
ever sniff. If this is over file:// then I guess we can do what we like.
The W3C position, last time I heard, is that sniffing is evil, very evil.
Assignee | ||
Comment 7•24 years ago
|
||
if we got here then there wasn't a content type. This is primarily intended for
local files. I believe this is a desired behavior for images in this scenario.
Updated•24 years ago
|
Priority: -- → P2
-> file, +qa
clarified summary.
Component: Networking → Networking: File
QA Contact: benc → tever
Summary: Unknown decoder should be smart enough to sniff for common image types... → file:// needs decoder to sniff file types
Comment 9•24 years ago
|
||
a=blizzard on behalf of drivers for the tip
Assignee | ||
Comment 10•24 years ago
|
||
fix checked in. To test, try opening some image local files that don't have
extensions.
instead of "test.jpg, test2.gif", rename the files to just be "test" and "test2".
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 12•24 years ago
|
||
This sounds like it affects more than just local files, but also ftp:// files
and headerless (HTTP 0.9) files w/ extensions?
You need to log in
before you can comment on or make changes to this bug.
Description
•