296199 - Firefox tries to display text/x-csrc files with less and sometimes hangs (freezes / stops)

Status: RESOLVED DUPLICATE of bug 120380

(Core Graveyard :: File Handling, defect)

Description

[Vincent Lefevre]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050517 Firefox/1.0.4 (Debian package 1.0.4-2)

When I try to open the above URL, Firefox says:

You have chosen to open
  tst-ieee754.c
which is a: C file
from: http://www.vinc17.org
What should Firefox do with this file?
  * Open with [less (default)]
  * Save to Disk
  [ ] Do this automatically...
[Cancel]  [OK]

If I click on OK, Firefox starts less (without a terminal) and completely hangs.
I need to kill it and remove the lock manually.

Reproducible: Always

Steps to Reproduce:
1. Open the above URL.
2. Click on OK.
Actual Results:  
Firefox hangs.

Expected Results:  
Firefox should not hang. I don't know why it asked for less (possibly a Debian
default), but if it can start less in a terminal, this would be OK for me. See
also bug 57342.

System: Debian unstable.

Comment 1

[Vincent Lefevre]

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).

Comment 2

[djpohly]

-> Core / File Handling

Comment 3

[Matthias Versen [:Matti]]

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.

Comment 4

[Andrew Schultz]

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.

Comment 5

[Vincent Lefevre]

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).

Comment 6

[Vincent Lefevre]

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.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

duplicate of bug 147274, right?

Comment 8

[Vincent Lefevre]

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.

Comment 9

[Gervase Markham [:gerv]]

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/

Comment 10

[Vincent Lefevre]

I cannot reproduce the hang with Firefox 1.0.7. Closing.

Comment 11

[A Mennucc]

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

Comment 12

[Vincent Lefevre]

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.

Comment 13

[Wayne Mery (:wsmwk)]

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

Comment 14

[Mike Hommey [:glandium]]

This is due to bug #120380