Red Hat Bugzilla – Bug 509400
firefox 3.5-beta4 consistently hangs when viewing JAVA webpages ....
Last modified: 2018-04-11 05:43:20 EDT
Description of problem:firefox 3.5-beta4.x86_64 consistently hangs when viewing certain webpages (http://radar.weather.gov/radar.php?rid=htx&product=N0R&overlay=11111111&loop=yes for example). Symptoms show after viewing the site for a few refreshes, then trying to go somewhere else, either by using the back button, the history dropdown, or the URL bar dropdown.
Version-Release number of selected component (if applicable):3.5-0.20.beta4.fc11
How reproducible:go to above URL & try it
Steps to Reproduce: go to above URL & try it
Actual results: browser hangs after viewing page for a few seconds, then trying to leave by back button or by trying to go to another site from URL bar dropdown menu
Expected results: browser views page AOK & can leave at will
Additional info: rest of OS is fully patched up as of Sunday.
Created attachment 350316 [details]
Yeah, unfortunately, I can reproduce it pretty well. The keyword is really "reload" ... it just works wonderfully on the first run, but once I start reloading page, trying to find some other place, firefox goes down.
Created attachment 350317 [details]
not completely sure, whether the second backtrace is related (happened when i was restarting firefox with among many others this weather page).
And yes, all this reproduction is done with
I 2nd the motion on reload/refresh, good observation, that is a much better description. Whenever the graphic box is somewhat occluded & has to refresh itself (like after the URL bar dropdown retracts & uncovers part of the gfx plot), the trouble starts ....
I just upgraded to 3.5.1 (about an hour ago) & this is still a problem (1st time I tried it) .... no problema, just notifying ....
Just upgraded to 3.5.2 (did yum -y upgrade, so I got everything) within the hour, this is still with us. No problema, just notifying ....
I just upgraded to 3.5.3 about an hour ago, & this is still with us. just notifying ....
upgraded to FF 3.5.4 today (full system yum upgrade), this is still flaky, just FYI ....
upgraded to FF 3.5.5 Sunday (full upgrade, 'yum -y upgrade'), & this is still with us, just FYI ....
I have just started seing something like this consistently on https://www.lsb.dk/lsb/netbank/logon/ , using F12 with updates-testing. However, sometimes it is only the "html page" that hangs; the menu, url and tab headlines are redrawn correctly, and using up/down arrows can apparently make it work again.
Is the problem discussed here so well-understood that no further stack traces are needed? Or do you see indications that my problem is different and should be filed separately?
Most likely duplicate of some of java bug, but not sure which one exactly, so leaving to Java folks to decide.
upgraded to FF3.5.6.x86_64 Saturday, this is still problematic, just FYI ....
I cannot reproduce either of the mentioned issues with upstream, which means that the fixes are there already. The next OpenJDK update in Fedora should inherit them.
I just noticed similar behaviour with the Citrix ICAClient-11.0-1.i386 browser plugin. That points in the direction of a Firefox bug.
This bug hurts! ;-)
I consistently see this:
- java (on one tab) is freezing so the tab isn't repainted on alt-tab, and often the FF headline and tab headers also isn't repainted.
- if I click on another (invisible) tab-tab then often nothing happens - the freezing tab is freezing FF completely
- pressing pgup/pgdn on the other page often makes it repaint
- ctrl-tabbing back to the Java tab often makes it repaint
So unless the java plugin violates som insecure cooperative protocol I can't see how this can be a java bug. And even if it violates such a protocol it is primarily a FF bug to expose such an interface.
I guess the java plugin has a way to tell FF that it takes responsibility for repainting a viewport. It seems like the plugin is allowed to claim a too big rectangle, and that the claim isn't suspended when another tab gets active.
However, this is just ramblings ...
Deepak, which next OpenJDK are you referring to? 1.6.2? Is a test build available somewhere? Building it seems to require infinite computing resources ...
I 2nd the motion on this description of what is happening, happens about 1 time out of 3, maybe 1/4 for me, have to shut the browser down & reinvoke it ....
(In reply to comment #15)
> Deepak, which next OpenJDK are you referring to? 1.6.2? Is a test build
> available somewhere? Building it seems to require infinite computing resources
Newer packages have been available for a while now:
I am going to close this issue. Please feel free to re-open if you can still reproduce it.
It looks better - I haven't seen the problem for a while now.
I still see it once in a while on the above-mentioned (originally referenced) URL, the browser locks up, slider, menus, etc. don't work, I have to kill it & start over. Happens about 1 time in 10, though I see other, less serious manifestations (update text for the window being plotted stalls before final 'applet started' text appears, but the browser still works OK) about 1 time in 3 or 4. YMMV & all that ....
As per my last response, I think this should be re-opened, what do I do to make that happen ?
As reporter you should be authorized to change "status" from "closed" to "assigned" - which I have done now.
My comment 18 was invalid - I still see what I described in comment 15.
From my POV it still seems like a problem with the repaint control, and I still think it looks more like a bug in Firefox or X than in Java...
I just upgraded to FF 3.5.8 yesterday A.M. & am still seeing artifacts of this, no crashes yet, but the 'fail to upgrade status for the plotted window' symptom 1st time I tried it .... just FYI ....
I'm keeping this open but FYI, I it is completely unreproducible on my end with the new plugin.
I tried loading the applet 8 times (including in parallel) and it works fine. The latest code is not in rawhide yet but it will be soon. Keeping this open till it makes it in rawhide.
I reliably see the minor manifestations (failure to upgrade status text for plotted window), as recently as just a few moments ago. No crashes yet (but only been to that page < 10 times in the last 24 hours). I'll keep watching, will post you if I get nothing (no crashes) in a few days. bit I am still sceptical ....
(In reply to comment #24)
> I'm keeping this open but FYI, I it is completely unreproducible on my end with
> the new plugin.
> I tried loading the applet 8 times (including in parallel) and it works fine.
> The latest code is not in rawhide yet but it will be soon. Keeping this open
> till it makes it in rawhide.
Deepak, could you be more explicit about the versions so we have a chance to know what to look for and test so we can give useful feedback?
(In reply to comment #26)
> (In reply to comment #24)
> > I'm keeping this open but FYI, I it is completely unreproducible on my end with
> > the new plugin.
> > I tried loading the applet 8 times (including in parallel) and it works fine.
> > The latest code is not in rawhide yet but it will be soon. Keeping this open
> > till it makes it in rawhide.
> Deepak, could you be more explicit about the versions so we have a chance to
> know what to look for and test so we can give useful feedback?
Yes, sorry about that. The (fixed) version I was referring to is in rawhide.
Fedora 11 and 12 have the older version of a plugin. The Java plugin in rawhide is a newer, rewritten plugin. It is only in rawhide atm, and this latest build should have it:
It seems like java-1.6.0-openjdk-plugin-220.127.116.11-36.b17.fc12.i686 is good for me. I have said that before, I think I have tested more thoroughly this time.
(In reply to comment #28)
> It seems like java-1.6.0-openjdk-plugin-18.104.22.168-36.b17.fc12.i686 is good for
> me. I have said that before, I think I have tested more thoroughly this time.
Grrr. I was wrong. It still happens here, but I can't figure out when.
I just had a lockup, had to punch out w/ the top-right WM exit button & start over .... no crash, but definitely fubared ....
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '11'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 11's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 11 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.