271961 - firefox + java + adblock crashes/hangs on www-rak.enst-bretagne.fr

Status: RESOLVED DUPLICATE of bug 240105

(Firefox :: General, defect)

Description

[Gummi]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.5) Gecko/20041108 Firefox/1.0

The UI doesn't respond anymore (and is not redrawn, using linux). Have to kill it.

Reproducible: Always
Steps to Reproduce:

Comment 1

[José Jeria]

WFM Win XP 1.0

Comment 2

[Gummi]

That's right, I have created a vanilla profile and found out that this only
happens when adblock is installed. There is a java applet on the page, which is
possibly part of the problem.
This will be likely to require a browser fix, because the browser shouldn't hang
even when misused by extensions that are limited to the javascript API.

Comment 3

[Gummi]

I can't confirm or close this with recent builds since there is no java plugin
available for x86_64.
If someone can test this page ( http://www-rak.enst-bretagne.fr ) with java
plugin + adblock and report if it crashes, by all means...

Comment 4

[Gummi]

I can't confirm or close this with recent builds since there is no java plugin
available for x86_64.
If someone can test this page ( http://www-rak.enst-bretagne.fr ) with java
plugin + adblock and report if it crashes, by all means...

Comment 5

[Marc Bejarano]

i can reproduce the mentioned behavior going to http://www-rak.enst-bretagne.fr
.  this is using firefox 1.0.1 on XP, JRE 1.4.2_06, and adblock 0.5.2.039 (aka
0.5 d2 nightly 39).  the browser doesn't totally hang.  the cpu is pinned and if
you attempt to close the misbehaving tab or window or exit the browser, it will
crash.  the same thing happens going to http://www.java.com.

upgrading to JRE 1.4.2_07 or 1.5.0_02 fixes the cpu usage and keeps the browser
from crashing, but still seems to leave the browser in a somewhat confused state
when the window is closed.  for instance, after visiting one of the pages with
these applets that cause the problem, i can't bring up the adblock prefs and
status bar sometimes says that firfox is still "Transferring data from
www-rak.enst-bretagne.fr".

disabling adblock and restarting the browser is the only good workaround i have
found.  just "disable"-ing adblock with its hotkey or from within its
preferences panel isn't good enough.

talkback ids for java.com:
TB4474173M
TB4474255Z
TB4474294Y
TB4474323Q

i'd have other talkback id's, but talkback.mozilla.org is currently misbehaving :(

Comment 6

[Marc Bejarano]

i can reproduce the mentioned behavior going to http://www-rak.enst-bretagne.fr
.  this is using firefox 1.0.1 on XP, JRE 1.4.2_06, and adblock 0.5.2.039 (aka
0.5 d2 nightly 39).  the browser doesn't totally hang.  the cpu is pinned and if
you attempt to close the misbehaving tab or window or exit the browser, it will
crash.  the same thing happens going to http://www.java.com.

upgrading to JRE 1.4.2_07 or 1.5.0_02 fixes the cpu usage and keeps the browser
from crashing when the window is closed, but still leaves the browser in an
unusably confused state.  for instance, after visiting one of the pages with
these applets that cause the problem, i can't bring up the adblock prefs, the
status bar keeps saying that firfox is still "Transferring data from
www-rak.enst-bretagne.fr", and i can't load new pages or exit firefox.  the
process needs to be force-killed.

disabling adblock and restarting the browser is the only good workaround i have
found.  just "disable"-ing adblock with its hotkey or from within its
preferences panel isn't good enough.

btw: i saw the same behavior on an OSX box with the java and adblock, but i
didn't do much testing.

talkback ids for java.com:
TB4474173M
TB4474255Z
TB4474294Y
TB4474323Q

i'd have other talkback id's, but talkback.mozilla.org is currently misbehaving :(

please confirm this bug, update the summary so that it reflects that the problem
is with multiple applets, and change the OS to "All".

ps: how do i earn the power to confirm bugs?

Comment 7

[Marc Bejarano]

the double post happened while firefox was in the aforementioned unusably
confused state.  obviously my comment was submitted, but the browser never
returned the page one normally gets after committing a comment :(

comment 5 should be diregarded.

Comment 8

[Marc Bejarano]

the issue i am experiencing with talkback is bug 210251.

more talkback ids:
TB4474436Q
TB4475293Z
TB4475314K

Comment 9

[Adam Hauner]

Marc's TB4474173M (all other incidents have similar stack):
0x00000000
nsLineLayout::ReflowFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsLineLayout.cpp,
line 1185]
nsBlockFrame::ReflowInlineFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3748]
nsBlockFrame::DoReflowInlineFrames 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3446]
nsBlockFrame::DoReflowInlineFramesAuto 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3347]
nsBlockFrame::ReflowInlineFrames 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3292]
nsBlockFrame::ReflowLine 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2456]
nsBlockFrame::ReflowDirtyLines 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2098]
nsBlockFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 817]
nsBlockReflowContext::ReflowBlock 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockReflowContext.cpp,
line 547]
nsBlockFrame::ReflowBlockFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 3068]
nsBlockFrame::ReflowLine 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2334]
nsBlockFrame::ReflowDirtyLines 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 2098]
nsBlockFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 817]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
CanvasFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsHTMLFrame.cpp,
line 554]
nsBoxToBlockAdaptor::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp,
line 884]
nsBoxToBlockAdaptor::DoLayout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBoxToBlockAdaptor.cpp,
line 626]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsGfxScrollFrameInner::LayoutBox 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 1264]
nsGfxScrollFrame::DoLayout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 1273]
nsBox::Layout 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBox.cpp,
line 1016]
nsGfxScrollFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsGfxScrollFrame.cpp,
line 873]
nsContainerFrame::ReflowChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 982]
ViewportFrame::Reflow 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsViewportFrame.cpp,
line 249]
IncrementalReflow::Dispatch 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 904]
PresShell::ProcessReflowCommands 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6401]
ReflowEvent::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6226]
PL_HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpcom/threads/plevent.c,
line 674]
0x778b0c24
nsPrintData::DoOnProgressChange 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsPrintData.cpp,
line 190]
_imp_??1nsCOMPtr_base

Comment 10

[Marc Bejarano]

reporter (or other empowered reader): can you update the summary so that in
mentions "crashes", as well?  and maybe re-assign this to the default owner
since we haven't heard from blake, here.

it would be great if somebody would confirm this, as well.

Comment 11

[Nickolay_Ponomarev]

See bug 240105 / bug 279668, also bug 136927. This seems a duplicate.

status whiteboard of 240105 says it may be fixed with latest java.

Comment 12

[Tristor]

(In reply to comment #11)
> See bug 240105 / bug 279668, also bug 136927. This seems a duplicate.
> 
> status whiteboard of 240105 says it may be fixed with latest java.

Looks like this is a dupe of 240105, resolving.

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