195476 - Browser fails to open .JPG links on webpages

Status: RESOLVED INVALID

(SeaMonkey :: General, defect)

Description

[Sam Lambert]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

If viewing a web page that contains links to .jpg files (forums, etc) Mozilla
1.3b will no longer open the .jpg in a new window.  It opens a "what should I do
with this file" dialog box, then won't remember the settings used in that dialog
regardless of what you set them to.  This worked in all previous versions.

The only option that works currently is downloading/saving the .jpg locally and
using a separate browser to look at it.  When you combine this with the already
reported bug of appending ".jpeg" to the name of downloaded .jpg files, this
becomes especially annoying.

At the minimum, the user should be allowed to specify opening the file with
Mozilla or another viewer (as a "helper" app), and that choice should be honored.


Reproducible: Always

Steps to Reproduce:
1. Locate a web page with a link to a .jpg file
2. Click the link
3. See what happens

Actual Results:  
You are prompted for "What should I do with this file."

Expected Results:  
Opened the .jpg in a new window/tab.

Have tested it with Multizilla and it behaves the same way.

This worked in all previous versions of Mozilla.

I searched Bugzilla for this and noted a similar problem reported against the
Mail client.  Please note this is a Browser issue.  And issue it is;  I'm going
back to version 1.2.1.

Comment 1

[thomas]

Attachment: Download Box - Mozilla obviously recognizes its MIME-type

This is what Mozilla gives me when trying to open a JPEG on a certain site.
Obviously not all sites are affected, since it just opens them on some sites.
The picture indicates the server sends the image as "image/jpeg", but still
Mozilla doesn't like something about it.
Just for the record, checked the server with Netcrafts "Whats that site
running", and it is "Apache/1.3.22 (Unix) PHP/4.0.4pl1 on Linux".

Comment 2

[Shaw Terwilliger]

I've noticed this problem with Debian unstable's version of Mozilla 1.3 on Linux
i386 (pool/main/m/mozilla/mozilla-browser_1.3-4_i386.deb).

I'm prompted to save JPEG files when the MIME type is image/jpeg, but the
extension isn't .jpg (like when they're served as the content of a php script).

Comment 3

[Vidar Haarr (not reading bugmail)]

WFM on WinXP SP1 trunk 2003081515.

Reporter: could you try to reproduce this using a recent nightly build from
<http://ftp.mozilla.org/pub/mozilla/nightly/latest/> ? If it works, please
resolve this bug as WFM. Thanks !

Comment 4

[Jon Henry]

Is this problem still occuring in recent Mozilla builds? If so, can you provide
a URL that demonstrates this? I don't know enough about the internals of how
Mozilla handles MIME types, but my best guess is the server is sending the file
with no type. Mozilla then does a little guess work looking at the file header
and sees it is probably a JPEG, but still pops up the dialog because it isn't
sure. Perhaps this behavior changed in between 1.2 and 1.3?

Comment 5

[Peter Bäck]

Here's an example,
http://kylie.artscience.net/vbb/attachment.php?s=3431583b5789417c4d4696a790d9ddd8&postid=335469

from this thread
http://kylie.artscience.net/vbb/showthread.php?s=3431583b5789417c4d4696a790d9ddd8&threadid=17285


Not working with:

Mozilla 1.5rc1

Mozilla Nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20030924

Firebird 0.6.1

Firebird Nightly: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a)
Gecko/20030924 Firebird/0.7+

But since this is an evangelism issue with vBulletinBoard sending incorrect
headers, the usual "Tough luck" -litany will ensue and the matter will remain
unadressed. This behaviour has after all been around since Mozilla 1.2.1, used
to work fine before. Sorry for venting, but the whole "Make the mountain come to
Moses" school of thought that would impose upon the world to adhere to Mozilla
instead of the other way around is, in my humble opinion, just going to shrink
the user-base to a select techno-elite who wouldn't tarnish their browsing
experience with content created by infidels who dare to slack from standards
just because it "Works with IE"...

Greetz,
 Peter

Comment 6

[Jon Henry]

Out of curiosity, do all sites that show this problem send the "image/pjpeg"
MIME type rather than "image/jpeg"? There are some old bugs (like bug 41449 and
bug 130564) that deal with Mozilla improperly handling that type, but they're
supposedly fixed. If Mozilla is once again choking on image/pjpeg (which stands
for progressive jpeg), perhaps they should be reopened.

Comment 7

[Shaw Terwilliger]

The vBulletin servers I'm using are sending back a content type of "image/jpeg".
 I think it's the "Content-disposition: atachment; filename=foo.jpg" line that's
breaking things.  ("atachment" is intentionally misspelled by vBulletin to cater
to an IE bug.)

I'm using FilterProxy to work around the bug by rewriting the header to be
"Content-disposition: inline;".

Comment 8

[Jon Henry]

Hmm. You're right, if the server is sending "Content-disposition: atachment"
then Mozilla would indeed popup with a helper app dialog. This is, of course,
exactly what it should be doing (see RFC 2183,
http://www.mhonarc.org/~ehood/MIME/rfc2183.txt). The site is saying explicitly
"give the user the option to save this file". This is a problem with vBulletin
which has supposedly been corrected in later versions
(http://bugzilla.mozilla.org/show_bug.cgi?id=185618#c11).

As disappointing as it may be for some, I think Peter's analysis is right,
although maybe a bit pessimistic. If Mozilla starts choosing to just ignore
Content-Disposition and display things inline, then lots of sites and Web apps
that depend on this functionality will break. There are far more bugzilla bugs
filed about Content-disposition: Attachment not working when we acted more like
IE does. This problem seems fairly limited to a few sites that choose to
intentionally not work properly.

I'm not a developer, I'm just trying to help out with QA, but I'm fairly certain
this will be resolved as invalid or wontfix, since again the browser is doing
what vBulletin had to go out of its way to ask it to do. If you'd like the
option to override that behavior, I suggest you vote/comment in bug 185618.

Comment 9

[Peter Bäck]

Forgive my pessimism, Jon. I whole-heartedly agree with the solution suggested
in the discourse attached to <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=185618">Bug 185618</a> as this
would allow the user to override non-standards compliant server behaviour
without making this default behviour. There my votes shall go.

Comment 10

[Jon Henry]

Thanks everyone for the replies helping to narrow down what the issue is. For
now, I'm going to mark this bug invalid, meaning that it is not really a bug
(with Mozilla, at any rate). If at any time someone comes across a server that
is *not* sending Content-disposition: attachment, but still causes Mozilla to
pop up the helper apps dialog, then by all means please reopen the bug or post a
comment here.