Ubuntu
firefox package

Firefox does not display a png image, but wants to open it with external app

Bug #15224 reported by Eric Feliksik
16
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
Medium
firefox (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Since recently, when clicking a link to a png image in Firefox, an "open with"
menu is showed. Instead, most likely the user just wants the picture to be
displayed in firefox.

Is this change intentional?

http://www.ubuntulinux.org/screenshots/document_view: http://www.ubuntulinux.org/screenshots/document_view

See original description
Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

assigning to av and adding serge and peterl for info on what the logic should
be. When the plug-in effort started: what was the logical process put into place
 -- what is the sequence of events?

Revision history for this message
In , Bzbarsky (bzbarsky) wrote :

confirming that we actually do this... (I was weirded out by it when looking
over this code sometime a few months back...)

Revision history for this message
In , Jason1-pobox (jason1-pobox) wrote :

I did some more investigating... I think this is essentially the same as bug
127963, which has been marked a duplicate of bug 96579, whose summary is
completely misleading.

Mozilla sometimes decides what to do with embedded objects too early (before
downloading the HTTP headers). The issue is (therefore) not limited to plugins
-- Mozilla has considerable problems with embedded internally-handled types like
text/html and image/gif when they have unusual file extensions.

Note that the correct logic depends on whether you think bug 95549 should be
fixed or not. (Personally I do not think it should be -- that would be a
disaster.) If it *is* fixed, then Mozilla will effectively ignore all TYPE
attributes for documents retrieved via HTTP.

Revision history for this message
In , Serhunt (serhunt) wrote :

I remember a discussion some time ago about this issue but don't remember what
we decided. Please correct me if I am wrong. TYPE attribute should take
precedence, if it is missing we should probably look at the HTTP headers and so
on. So in order of precedence:
  1. TYPE attribute
  2. mime type reported by server
  3. OS level file ext to mime type mapping
  4. choose plugin by file extension only

The first two are most the controversial I would guess.

Revision history for this message
In , Jason1-pobox (jason1-pobox) wrote :

In my opinion, plug-in-registered file extensions (4) should have priority over
OS mappings (3). Actually, I think OS mappings should be ignored altogether when
selecting a plug-in.

If OS mappings are used, then the plug-in selected will sometimes depend on what
(not-necessarily-browser-related) applications the user happens to have
installed on his computer, and even on the order in which they were installed,
and how they are configured. Although this won't apply in most cases (because a
Content-Type header will be present), situations like this can be very
frustrating for plug-in developers and users.

An exception could perhaps be made for the "file:" URL scheme, but it may not be
worth the extra confusion.

Revision history for this message
In , Srgchrpv (srgchrpv) wrote :

*** Bug 112335 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Jesse Moorman (moorman-jesse) wrote :

My Mozilla 1.0 installation [W2K] not only gets the wrong plugin, it crashes on
the 'object' and 'embed' links on the test URL.

I came to search Bugzilla because recently Mozilla is trying to open or to
save-to-disk almost everything as a PDF files even if NOT PDFs. I'm not sure if
that bug is different, or if it has been reported. I'm not really sure how to
check the MIME types, so I don't know how to test this one against the Bugzilla
discriptions.

Revision history for this message
In , Rubydoo123 (rubydoo123) wrote :

peter : plug-in branch work

Revision history for this message
Eric Feliksik (milouny) wrote :

Since recently, when clicking a link to a png image in Firefox, an "open with"
menu is showed. Instead, most likely the user just wants the picture to be
displayed in firefox.

Is this change intentional?

Revision history for this message
Hervé Cauwelier (bug tracking) (debian-oursours) wrote :

Oddly enough, it appeared to work as expected with some images from a same
batch. Really weird.

Revision history for this message
Travis Watkins (amaranth) wrote :

I don't think this is just a Firefox issue. I have a nightly of Firefox I get
from mozilla.org and it does this too. That would make it a mime type issue, I
think. It doesn't always happen but I can't seem to figure out why.

Revision history for this message
Peter Odding (peterodding) wrote :

(In reply to comment #2)

Disclaimer: I have no experience with Gecko's internals, so everything here is
just guessing.

I've encountered this issue in Debian Sarge. Assuming the Ubuntu package is
based on Debian's this doesn't really get us any further. Before encountering
this bugzilla page, and before even trying Ubuntu, I had come to the same
conclusion as Travis Watkins (mimetype issue). I'll see if I can test this out
with a local server and the LiveHTTPHeaders extension, I'll report the results
here tomorrow. If this is indeed a mimetype issue, I have absolutely no idea
whether this is resolveable. I don't think file extensions will be of any help,
since their not mandatory, and I don't know whether Gecko is smart enough to
'sniff' a filetype. It's probably to CPU intensive to do this for each received
file/stream, or even for each file/stream that can't be displayed, e.g. is
offered as a download.

ps. First ever Bugzilla posting, so forgive me for any wrong terminology.

Revision history for this message
In , Ian Jackson (iwj) wrote :

Another strange effect of this bug (these bugs?) is that it is possible to get
firefox to display a dialogue box:

  You have chosen to open ubuntu1.png
  which is a: PNG image
  from: http://www.ubuntulinux.org

  What should Firefox do with this file?
  (*) Open with [ Image Viewer (default) ] [V]
  ( ) Save to Disc
  [ ] Do this automatically for files like this from now on

which is obviously completely barking !

I can reproduce this at the moment as follows:
  1. Visit http://www.ubuntulinux.org/screenshots/document_view
  2. Left-lick on the top-left image.

The image has URL http://www.ubuntulinux.org/include/ubuntu1.png and the server
erroneously says Content-Type: text/plain.

Firefox should believe the Content-Type. If it is thought desirable not to
believe it in some cases (which I strongly disagree with) then it should
entirely fail to believe it and entirely believe the file extension instead.

What we have at the moment is Firefox being confused - it can't make up its mind
what the file type is.

Revision history for this message
Ian Jackson (ijackson) wrote :

In fact, there are two problems here. Firstly, the website is supplying an
incorrect Content-Type of text/plain. This is the same as
https://rt.admin.canonical.com/Ticket/Display.html?id=38

Secondly, this error causes Firefox to become confused about the type of the
file. This latter is the same as upstream bug
https://bugzilla.mozilla.org/show_bug.cgi?id=140975

Revision history for this message
Alexandre Otto Strube (surak) wrote :

ijackson confirmed.

Changed in firefox:
status: Unconfirmed → Confirmed
Revision history for this message
Ian Jackson (ijackson) wrote :

It's true that this bug is in Ubuntu and should be fixed. But the problem is a hideous mess of fundamentally incorrect algorithms in Mozilla and we don't have the knowledge or resources in Ubuntu to fix this problem for us or to maintain the resulting patch.

I think this issue should be addressed upstream.

So I am setting this bug to Rejected (LP assure me that this is the right status even though I agree with the complaint).

Changed in firefox:
status: Confirmed → Rejected
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Unconfirmed → Confirmed
Ian Jackson (ijackson)
Changed in firefox:
assignee: ijackson → nobody
Bug Watch Updater (bug-watch-updater)
Changed in firefox:
importance: Unknown → Medium
Revision history for this message
In , Mariomihai22 (mariomihai22) wrote :

Based on Comment 3 Resolved Duplicate.

*** This bug has been marked as a duplicate of bug 96579 ***

Bug Watch Updater (bug-watch-updater)
Changed in firefox:
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.