611511 - Firefox 4.0.1 becomes unresponsive when displaying large FTP directories

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Shlomi Fish]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre

When I access the URL ( ftp://mirror.isoc.org.il/pub/mandriva/devel/cooker/i586/media/main/release/ ), firefox becomes unresponsive for many seconds, and the menus, buttons, tabs, etc. won't respond. This also happens with other pages and also HTTP pages.

I tried it in safe mode and was able to reproduce it there. I'm on Mandriva Linux Cooker on a Pentium 4 2.4 machine. I recall this started only a few days ago. I'm using the firefox-latest-nightly.

Reproducible: Always

Steps to Reproduce:
1. Type firefox -no-remote -safe-mode.
2. Go to the URL.
Actual Results:  
Firefox become unresponsive.

Expected Results:  
Firefox should load the page while still allowing to interact with it.

Comment 1

[Kevin Brosnan]

Loads fine for me - Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101111 Firefox/4.0b8pre

Comment 2

[Shlomi Fish]

(In reply to comment #1)
> Loads fine for me - Mozilla/5.0 (X11; Linux x86_64; rv:2.0b8pre) Gecko/20101111
> Firefox/4.0b8pre

Hmmm... interesting - I can now reproduce the offending behaviour also in Opera, in Konqueror (of KDE-4.6.x-pre) and to a lesser extent in chromium-browser too. So I guess it's a more global problem with my system and not a Firefox-specific bug. I'll investigate further.

Comment 3

[Nickolay_Ponomarev]

Any news, should this be resolved as works for me?

Comment 4

[Shlomi Fish]

(In reply to comment #3)
> Any news, should this be resolved as works for me?

I'm still getting this problem and now I also noticed that scrolling using the mouse's scrollwheel is unresponsive, and that it takes the window some time to redisplay after I switch to it from a different window. But the opera browser exhibits the original problem as well.

Regards,

-- Shlomi Fish

Comment 5

[Shlomi Fish]

(In reply to comment #4)
> (In reply to comment #3)
> > Any news, should this be resolved as works for me?
> 
> I'm still getting this problem and now I also noticed that scrolling using the
> mouse's scrollwheel is unresponsive, and that it takes the window some time to
> redisplay after I switch to it from a different window. But the opera browser
> exhibits the original problem as well.
> 

OK, now that I checked I seem to be getting an even worse problem with the http:// URL:

http://mirror.isoc.org.il/pub/mandriva/devel/cooker/i586/media/main/release/ 

Firefox stalls there for many seconds and is completely unresponsive.

Regards,

-- Shlomi Fish

Comment 6

[Shlomi Fish]

Attachment: Perl program to populate the current directory with 6,000 files with random filenames.

By some guidance from someone on the Cooker mailing list, I've written this Perl program to populate a directory with 6,000 files with random filenames. After I run it and invoke "firefox .", Firefox takes some time to load it and still stalls during loading the file:/// display. So I guess the problem is not networking related.

I recall having similar problems when I had a fonts misconfiguration problem, so maybe that's related.

Comment 7

[Shlomi Fish]

Now that I've ran <<< strace -f -o firefox.strace firefox -no-remote -safe-mode ./TEMP/firefox-611511-test/ >>> and then did tail -f firefox.strace > foo I see at the top 300K lines of the files repetitive system calls such as:

{{{{{{{{{{{{{{{{{{{{{{{
15926 futex(0xafbfbb88, FUTEX_WAIT_PRIVATE, 10831, NULL <unfinished ...>
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 futex(0xafbfbb88, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xaee29c54, 10832 <unfinished ...>
15926 <... futex resumed> )             = 0
15926 futex(0xaee29c54, FUTEX_WAKE_PRIVATE, 1) = 0
15926 futex(0xafbfbb88, FUTEX_WAIT_PRIVATE, 10833, NULL <unfinished ...>
15905 <... futex resumed> )             = 1
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2213, ...}) = 0
15905 futex(0xafbfbb88, FUTEX_CMP_REQUEUE_PRIVATE, 1, 2147483647, 0xaee29c54, 10834) = 1
}}}}}}}}}}}}}}}}}}}}}}}

And so repeating themselves many thousands of times. Why does Firefox keep repeating this?

Regards,

-- Shlomi Fish

Comment 8

[Nickolay_Ponomarev]

> OK, now that I checked I seem to be getting an even worse problem with the
> http:// URL:

Despite seeming similar from the user perspective, the http://, ftp://, and file:// listings work quite differently. The whole process can be split into 3 steps:
1. Getting a list of files with their names/sizes/modification dates.
2. Converting this list into an HTML page
3. Rendering the HTML page

In the http:// example you mentioned, 1+2 happen on the server, Firefox gets the complete page from the server and just renders it.
For file:// and ftp:// we also generate the table from the file data, but the step (1) is implemented by different code, obviously.

So please keep this bug about one issue only. Feel free to file separate bugs on other issues.

Which of the 3 cases "started only a few days ago" relative to 20101111, as you say? Can you pinpoint the exact two builds this changed between (among http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-mm-dd-hh-mozilla-central/)?

(FWIW, I tried all three cases on Mac and they all are a bit sluggish, but none of the 3 takes long. The file access and time formatting code (nsDateTimeFormat*) are different on different OSes though.

Shark/Activity Monitor weren't able to get a meaningful profile out of the nightly I'm using... )

Comment 9

[Shlomi Fish]

(In reply to comment #8)
> > OK, now that I checked I seem to be getting an even worse problem with the
> > http:// URL:
> 
> Despite seeming similar from the user perspective, the http://, ftp://, and
> file:// listings work quite differently. The whole process can be split into 3
> steps:
> 1. Getting a list of files with their names/sizes/modification dates.
> 2. Converting this list into an HTML page
> 3. Rendering the HTML page
> 
> In the http:// example you mentioned, 1+2 happen on the server, Firefox gets
> the complete page from the server and just renders it.
> For file:// and ftp:// we also generate the table from the file data, but the
> step (1) is implemented by different code, obviously.
> 
> So please keep this bug about one issue only. Feel free to file separate bugs
> on other issues.
> 
> Which of the 3 cases "started only a few days ago" relative to 20101111, as you
> say? 

The FTP one was the one I noticed first as I mentioned in the original report.

> Can you pinpoint the exact two builds this changed between (among
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-mm-dd-hh-mozilla-central/)?
> 

It also happens with Firefox 3.6.13 now that I tried it (in a new profile.). And like I said it also happens on different browsers.

> (FWIW, I tried all three cases on Mac and they all are a bit sluggish, but none
> of the 3 takes long. The file access and time formatting code
> (nsDateTimeFormat*) are different on different OSes though.
> 
> Shark/Activity Monitor weren't able to get a meaningful profile out of the
> nightly I'm using... )

Maybe you can try in a Linux virtual mahcine and see if you can reproduce it there.

Comment 10

[Tyler Downer [He/Him]]

This bug was reported using a pre-release version of Firefox 4. Now that Firefox 4.0.1 final has been released, can you please update and retest your bug? A fresh profile would be a good starting place to test, 
http://support.mozilla.com/kb/Managing+profiles. If you continue to see the issue, can you please update this bug with your results?

Filter: firefox4prebugsunco

Comment 11

[Shlomi Fish]

(In reply to comment #10)
> This bug was reported using a pre-release version of Firefox 4. Now that
> Firefox 4.0.1 final has been released, can you please update and retest your
> bug? A fresh profile would be a good starting place to test, 
> http://support.mozilla.com/kb/Managing+profiles. If you continue to see the
> issue, can you please update this bug with your results?
> 
> Filter: firefox4prebugsunco

I continue to experience the reported problem with firefox-4.0.1 from mozilla.org in a fresh profile on Mandriva Cooker.

Comment 12

[:aceman]

Is this still a problem on Firefox 7 or later?

Actually, if you see the non-responding Firefox only when the page is loading and not once it is loaded, then this is known problem.
Possible duplicates: bug 216358 and bug 595574.

Comment 13

[Shlomi Fish]

(In reply to :aceman from comment #12)
> Is this still a problem on Firefox 7 or later?
> 
> Actually, if you see the non-responding Firefox only when the page is
> loading and not once it is loaded, then this is known problem.
> Possible duplicates: bug 216358 and bug 595574.

Well, my computers now are faster than what I had back then, but it seems I'm still getting a delay of unresponsiveness (although a shorter one).

Comment 14

[Leonard Camacho [:lcamacho]]

I can reproduce this with nightly, it becomes unresponsive for a short period while it loads the ftp directory, I can't scroll smoothly while waiting.

Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/16.0 Firefox/16.0a1

Comment 15

[Shlomi Fish]

With this URL - http://mirror.math.princeton.edu/pub/mageia/distrib/cauldron/x86_64/media/core/release/ - and with a local file:/// directory with 36k files, everything seems fine on Firefox 57.0.2. Resolving as FIXED.