Java or Flash implementation causing extreme slowness, freeze, and/or crash




11 years ago
8 years ago


(Reporter: BlueRubicon+BugZilla, Unassigned)


Firefox Tracking Flags

(Not tracked)





11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031004 Minefield/3.0b5pre

OpenSuSE 10.3, KDE 3.5, and Windows Vista (pre SP1), Latest Java and Flash releases, FF since 3b3 and current 3b5pre (both repository version and Mozilla build)

Some sites, this one in particular after starting login, cause Firefox (3, not 2 or other browsers, except SeaMonkey release) to slow down to a crawl, often causing it to freeze and having to be killed, or FF crashes after PIN confirmation.  Don't know if this is related to Java or Flash implementation.  Sometimes reinstalling Java and Flash packages corrected the problem, but not in the current nightly), and it doesn't seem to be a broken site issue.

Reproducible: Always

Steps to Reproduce:
1.Go to in FF beta (or SeaMonkey release)
2.After login and entering PIN on next screen
3.Slow, freeze, and/or crash

Expected Results:  
Account page

This does not happen in FF 2 release or other browsers, except the current SeaMonkey release.  Other sites where this occurs seem to be heavy with Flash and Java implementation.

Comment 1

11 years ago
I get the same symptoms if I go to with the latest FF3 nightly (running Ubuntu Linux 7.10), possibly due to the Flash banner at the top.

However there are no problems when I try the same sites with Firefox

Comment 2

11 years ago
I've tested several other sites with the latest nightly build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008042204 Minefield/3.0pre ID:2008042204) and it seems that using the the image uploader on Photobucket causes similar problems.

Is this still unconfirmed?

Comment 3

11 years ago
Ah, it seems that this bug is a duplicate of Bug 429903

Comment 4

11 years ago
This does seem to be the same type of problem (but please note the breadth of this problem below).  Noticing the Adblock and NoScript comments in Bug 429903 makes me wonder about handling of script timeouts.  But blocking the scripts and media content doesn't solve the problem -- clean profiles with no extensions installed still allow the same behavior as when blocking scripts and media on certain sites.  This seems to support a conclusion that the problem lies in the handling of timeouts which result in the bottleneck of stopping of further page rendering by the browser (There have been several confirmed reports of this related to the rendering engine).  But the way in which the browsers are halting rendering is not consistent as noted by this comment:

"I have noticed something else in the last few days which I initially just put
down to my network connection but now I'm not so sure, I'm not even sure if
it's related to this. Basically quite a few times I'm getting a timeout
accessing a site, click refresh and it's fine. I'm going to do some more

This behavior does seem related and again indicates an underlying problem with the rendering engine halting for lack of clear rules for handling of timeouts or unresponsive media.  Additionally, it is clear that the problem(s) can halt not just the rendering of the current page/tab, but can halt the operation of the entire program.  So is this a problem just with the rendering engine and its protocols or is there also a problem with the programs' operational controls over the rendering engine (which seems to be the case)?

To reiterate, this is not a problem unique to Firefox as it occurs in SeaMonkey as well, and on multiple OS platforms, and with or without extensions.  The latest beta repo release from the OpenSuSE Build Service (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032600 SUSE/2.9.95-3.2 Firefox/3.0b5) has drastically reduced this occurrence (in that build only), however, the latest build from Mozilla for FF3b5, and SeaMonkey releases (both Mozilla and Build Service repo) and development builds, still allow this behavior.

Comment 5

11 years ago
that's silly. we make nightly builds too:

if the problem is gone on trunk, then we don't need an open bug complaining about some previous release, the problem should be gone when we make our next release.

Comment 6

11 years ago
It has not been, and is not now, gone from latest trunk builds, either for Windows or Linux OS builds of Firefox, and it exists in release and latest development builds of SeaMonkey as well.

Comment 7

11 years ago
flash still crashes firefox 3pre (today's nightly) on my EEE. I don't know, this is kinda frustrating.
Is this issue still occurring with Firefox 3.0.4, Flash 10, and Java 6 Update 10? Please read

Comment 9

10 years ago
Yes to the closing (disappearance); No to the slowdowns.  FF 3.0.4, Flash 10, and the latest Java releases.  It is not occurring in SeaMonkey v2.0a1, but it is in the 1.x release.

Some feedback via running from a terminal indicates some kind of interaction problem between the Java JVM, libmozjs in XULRunner, and possibly some flash components.  Why it doesn't manifest in SeaMonkey v2.0a1, etc..., I don't know.

The slowdown seems to have been alleviated, but the crashing (sometimes FF just dissappears/closes with no self-awareness of crashing) has gotten worse.  Some sites cause it to go constantly, while others are intermittent; and soemtimes it just closes on startup before loading any sites, with feedback indicating the problems noted aboce and below.  Allowing or disallowing scripts to run on a site makes no difference, which points to program code rather than site scripting.

This is identical to the problem that Azureus/Vuze is having.  They tend to blame the Sun JVM, but they use the same flash and XUL components and terminal feedback indicates, as noted above, the it is programs' utilization of swt and XUL in relation to the JVM.  Replacing Sun's JVM with opensource packages still results in the same errors, so that would seem to point again to the programs' utilization of flash and XUL (js) with the JVM.

Comment 10

10 years ago
if there's console output, could you attach it? so far you've provided absolutely nothing useful and this bug is very close to being killed.

note that java or flash causing the browser to be slow or freeze or crash is expected behavior and if you don't like it, you're expected to complain to your java or flash vendor. (we have bugs for changing this behavior, however your bug won't improve things)

Comment 11

10 years ago
Kill it if you wish.  Reporting a bug, and giving information and thought, does not commit one to being a nurse-maid.

The console output is sparse, because the program has no direction to provide clues to the faults, so one has to speculate...  Just like one has to speculate about the attitude you're projecting.  Read more, think more, bitch less.

You have a funny notion of "expected behavior".  Trying to blame Java or flash (old and established technologies that haven't gone through as much sweeping change as Mozilla and FF) won't solve the problem.  When the problem surfaces in only a few programs that make use of the Java and flash code, then one can safely assume its the programs' use of that code that is causing the problem(s).

Comment 12

10 years ago
well, refusing to provide whatever meager/sparse information you have does guarantee we won't be able to do anything with it.

as for java and flash, they've both undergone major changes recently (java had the api it uses to talk to browsers replaced, and flash just did a major rewrite from 9 to 10).

if you want "support", please visit

this system is for real bugs, and yours isn't.
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE

Comment 13

10 years ago
As you wish.
You need to log in before you can comment on or make changes to this bug.