"open with" cannot define behaviour depending on extension

Bug #133131 reported by Manuel López-Ibáñez on 2007-08-17
2
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Invalid
High
firefox (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: mozilla-firefox

1. Open a *.diff file
2. A dialog appears that says it is a "BIN file". Odd but MIME info or other magical things may not be working. Nonetheless, file extension is "diff".
3. Options are: 1) Open with less (default) 2) Save to disc. The option "Do this automatically for files like this from now on" is locked on disabled.

What I would expect:

1. Never, never, never, never offer to open anything with "less". This is so useless, that it makes me cry.
2. Offer the option "Do this automatically for files like this from now on", either based on the MIME type or, if that fails, on the extension.
3. Extra points if FF is able to recognize the extension and don't say that this is a BIN file.

I forgot to say: I've tried with Mozilla (the Debian package too), which also
asks me if I want to display the file with "less", but it does not hang (it
doesn't display the file either in any way).

-> Core / File Handling

Please try it again with a Mozilla.org Firefox build.
Bugs from other builds (like Debian) are invalid here because they add there own
patches.
And if you try a Mozilla.org build use a nightly trunk build because the Gecko
FF1.0.4 is already 12+ months old.

1. associating any file type with less is silly. I'd guess you can thank Debian
for that (not their Firefox package)
2. this worksforme with linux firefox 1.0.4 and trunk. less runs in the console
and firefox continues working fine.

With the trunk Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050601
Firefox/1.0+, Firefox doesn't hang. But Firefox still launches a useless "less"
process, which runs in the background (until I kill it).

In fact, the trunk also hangs. The hang occurs only when Firefox is started from
my window manager (instead of a terminal). I assume that this is because there
is no attached tty.

duplicate of bug 147274, right?

The report for bug 147274 says: "a ghostscript window will pop up, but Mozilla's
windows will cease to repaint until the process is killed". But here, when
"less" is killed (with kill -9, the only signal that works), it remains a zombie
and Mozilla is still frozen. So my bug is much more serious.

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/

I cannot reproduce the hang with Firefox 1.0.7. Closing.

hi

I use Debian/etch/4.0 and I use the iceweasel version of Firefox 2.0
(unfortunately, there is no build of Firefox 2.0 for amd64 around...
so, I am sorry, I cannot test if what follows really does
happen with Firefox proper - although I would bet that it does)

Suppose that I start
$ iceweasel http://tonelli.sns.it/pub/mennucc1/fuzzyocr/fuzzyocr_2.3b-1.dsc &
from the terminal; that link is of type text/pgp :
then iceweasel offers to open with 'less' ; if I accept,
immediatly the shell reports
 [1]+ Stopped iceweasel
since 'less' wants to access the terminal;
if I foreground iceweasel, then less works on the terminal, and I can
hit 'q' to exit it, and then I can background iceweasel again.

If I start
$ nohup iceweasel http://tonelli.sns.it/pub/mennucc1/fuzzyocr/fuzzyocr_2.3b-1.dsc &
then iceweasel does not hung, and the output of less goes into 'nohup.out'.

If I start iceweasel from a Gnome menu, then the output of less goes into
 ~/.xsession-errors

Anyhow, this bug is not fixed.

The correct way to fix this bug is that iceweasel/firefox must care for the
 'needsterminal' keyword in MIME specification:
$ grep less /etc/mailcap
text/plain; less '%s'; needsterminal
text/*; less '%s'; needsterminal

The above means that less needs a terminal, and so
1) either iceweasel/firefox starts a terminal and less into it ;
 for example, the command
   x-terminal-emulator -e less /tmp/fuzzyocr_2.3b-1.dsc
 works fine in Debian

2) or, otherwise, iceweasel/firefox must ignore any mailcap
  entry that has the keyword needsterminal in it

a.

ps: the original URL does not trigger the bug on Gnome in Debian, since
 Firefox opens it with gedit

ps: please reopen the bug, I do not have powers to do it

I'm reopening the bug. Indeed, the hang seems to occur in some cases only and in fact, the process is stopped. Since there is a workaround concerning this hang, I also downgrade the severity.

Carsten, do you know someone who can further refine the bug?

Binary package hint: mozilla-firefox

1. Open a *.diff file
2. A dialog appears that says it is a "BIN file". Odd but MIME info or other magical things may not be working. Nonetheless, file extension is "diff".
3. Options are: 1) Open with less (default) 2) Save to disc. The option "Do this automatically for files like this from now on" is locked on disabled.

What I would expect:

1. Never, never, never, never offer to open anything with "less". This is so useless, that it makes me cry.
2. Offer the option "Do this automatically for files like this from now on", either based on the MIME type or, if that fails, on the extension.
3. Extra points if FF is able to recognize the extension and don't say that this is a BIN file.

The upstream bug for showing "less" as a default application is:
https://bugzilla.mozilla.org/show_bug.cgi?id=296199

that wouldn't fix points (2) or (3).

A related extension that alleviates the problem:
http://www.spasche.net/mozilla/

Rolf Leggewie (r0lf) wrote :

I got annoyed by this from time to time, too. Setting to confirmed.

Changed in mozilla-firefox:
status: New → Confirmed
Changed in firefox:
status: Unknown → New

This is due to bug #120380

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

Changed in firefox:
status: New → Invalid
Changed in firefox:
importance: Unknown → High
status: Invalid → Unknown
Changed in firefox:
status: Unknown → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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