8290 - Pressing BACK button crashs the browser

Status: VERIFIED FIXED

(Core Graveyard :: Java: OJI, defect, P3)

Description

[Paul Wyskoczka]

Apprunner build is 6/15
RJE is 1.3
Occurs on Mac and Windows NT

Steps:
1. Launch the browser
2. Run the following url:
http://blues/users/bsharma/publish/ojitests/tags/applet/align.html
3. Browser crashes

Comment 1

[leila.garin]

Using 11/16/99 Mozilla build and jdk1.3 build "O" on WinNT,
loading this url would crash the browser.

Comment 2

[leger]

Clearing FIXED resolution due to reopen.

Comment 3

[leger]

Moving milestone from M9 to M12 since M9 way gone:-)

Comment 4

[av (gone)]

It crashes in JPINS32.dll. Reassigning to Java folks for investigation.

Comment 5

[drapeau]

*** Bug 11656 has been marked as a duplicate of this bug. ***

Comment 6

[Antti Näyhä]

Could we have a public test case?  Thanks.

Comment 7

[leila.garin]

Added the test case in the attachment.

Comment 8

[leila.garin]

Attachment: html file that contains the align tag tests

Comment 9

[chris hofmann]

move to m14. let me know if fixes are available. thx.

Comment 10

[Prashant Desale]

This one happens on Windows-95 too.
I tested with todays build. [2000-01-24-09], and its crashing.

Here is simple testcase I'm providing. [Coming attachment.]

Just load this attachment and you'll see crash.

Comment 11

[Prashant Desale]

Attachment: Attached testcase with applet with right alignment.

Comment 12

[drapeau]

We have a blocker on this bug: the current Java Plug-In doesn't work with
current Mozilla builds, due to yet another set of Mozilla API changes.  We are
working to get Sun's internal source tree for JDK/Plug-In modified to work with
current Mozilla builds.  Only then can we begin working on this bug.

We have proposed solutions, have notified JDK Plug-In development team, and are 
working with them to help implement their upgrade.  Will update this bug when 
that is done.

Comment 13

[leger]

Adding "crash" keyword to all known open crasher bugs.

Comment 14

[edburns]

I'm better set up to test this. But I can't test it until PAW makes the applet 
available as an attachment to this bug, or as an externallay available applet.

Marking INVALID so PAW can post the applet.

Comment 15

[Paul Wyskoczka]

Attachment: Test case for align

Comment 16

[Paul Wyskoczka]

Added testcase for align as an attachment.  Reopening the bug.

Comment 17

[bsharma]

For this applet, the browser crashes on the Windows 98 platform as well. It 
gives "Runtime Error!. Abnormal Program Termination".

Comment 18

[bsharma]

For this applet, the browser crashes on the Windows 2000 platform as well.
Build ID: 03-17-00 Beta 1

Comment 19

[drapeau]

Pushing off a couple of milestones.

Comment 20

[drapeau]

Adding "nsbeta2" keyword to nominate, since this causes a crash.  Crashes ain't
good.

Comment 21

[leger]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 22

[edburns]

Using Stanley's 2 June JPI patch with a MOZ_DEBUG=1 Mozilla build from 9 July 
this appears to work exactly as it should.  

Marking FIXED.

Comment 23

[Paul Wyskoczka]

Verified in build 2000071120

Comment 24

[rpallath]

The page shows up correclty and align does work as indicated
but after this page is loaded, clicking  on browser Back  button  does nothing
Typing another URL does nothing

Choosing URL from 'GO menu option' does nothing.

So goes into a hung state

Comment 25

[shrirang khanzode]

qa:shrir

Comment 26

[leger]

Setting ETA to 7/26, if not fixed by end of tomorrow, will minus.

Comment 27

[edburns]

I notice that the nsWindow message proc is still running even after the hang, 
but when I "break" the running execution after the hang the stack trace always 
shows:


NTDLL! 77f677ef()
KERNEL32! 77f1c7d6()
JVM! 08057890()
MSVCRT! 7800248d()
KERNEL32! 77f04f2c()

I think this is related to lifecycle issues again.  It appears the plugins are 
not being properly stopped.

Comment 28

[edburns]

I find that the bug occurs even if I modify the testcase to have a single 
applet.  This rules out the possibility that multiple applets have something to 
do with this bug.

Comment 29

[edburns]

reassign

Comment 30

[edburns]

Hi Stanley,

Environment: ladybird/JPI and mozilla OJI branch from AM 25 July 2000.

Here's what I observe when I visit a page with an applet and press back.  

I set the following breakpoints:

1. nsObjectFrame.cpp nsObjectFrame::Destroy() where it calls inst->SetWindow
(nsnull)

2. awt_Component.cpp AwtComponent::WindowProc() where it handles the WM_DESTROY
 message

3. nsWindow.cpp nsWindow::ProcessMessage() where it handles the WM_DESTROY 
message.

When I press back I find that the breakpoints are hit in the following order:

1, 3

Breakpoint 2 is never hit.  

When breakpoint 3 is hit, the stack trace ends with:

nsWindow::ProcessMessage(unsigned int 2, unsigned int 0, long 0, long * 
0x0012e2ec) line 2650
nsWindow::WindowProc(HWND__ * 0x057e0392, unsigned int 2, unsigned int 0, long 
0) line 829 + 27 bytes
USER32! 77e7288d()
USER32! 77e72918()
CJavaPluginView::PluginWndProc(HWND__ * 0x057e0392, unsigned int 2, unsigned 
int 0, long 0) line 546 + 31 bytes
USER32! 77e71ab7()
USER32! 77e71a77()
NTDLL! 77f7624f()
nsView::~nsView() line 161

I think this is because CJavaPluginView::PluginWndProc() delegates the handling 
of the WM_DESTROY message to the window from which it subclassed, which is an 
nsWindow.  Either that or it delegates it to its parent window.  

MY QUESTION: Is this the correct ordering?

Comment 31

[stanley.ho]

Ed,

1. nsObjectFrame.cpp nsObjectFrame::Destroy() where it calls inst->SetWindow
(nsnull)

2. awt_Component.cpp AwtComponent::WindowProc() where it handles the WM_DESTROY
 message

3. nsWindow.cpp nsWindow::ProcessMessage() where it handles the WM_DESTROY 
message.

> I think this is because CJavaPluginView::PluginWndProc() delegates the 
> handling of the WM_DESTROY message to the window from which it subclassed, 
> which is an nsWindow.  Either that or it delegates it to its parent window.  
>
> MY QUESTION: Is this the correct ordering?

CJavaPluginView::PluginWndProc() is a hook into the browser's plugin window 
message loop. Therefore, when WM_DESTROY is sent to the native window, 
CJavaPluginView::PluginWndProc() will get a hold of it, before the native 
window message loop process it.

From the MS documents:

"The WM_DESTROY message is sent when a window is being destroyed. It is sent to 
the window procedure of the window being destroyed after the window is removed 
from the screen. "

"This message is sent first to the window being destroyed and then to the child 
windows (if any) as they are destroyed. During the processing of the message, 
it can be assumed that all child windows still exist."

Therefore, the correct order should be 1, 3, 2 in this case.

Comment 32

[edburns]

Added Stanley to CC.

Comment 33

[edburns]

Stanley, so you're saying that it is CORRECT that setWindow(nsnull) should 
occurr BEFORE the window is destroyed?

Comment 34

[edburns]

Changed ETA to 8/3

Comment 35

[leger]

Per todays PR2 nsbeta2+ blocking bugs review, no me left.  moving from 
[nsbeta2+] to [nsbeta2-].  Putting on nsbeta3 nominee radar.  If you get a fix, 
put it on the trunk, not the branch.

Comment 36

[shrirang khanzode]

This does not crash anymore on windows build 2000081508M18.Applets load fine on
this testpage. Changing OS to Mac.

Comment 37

[shrirang khanzode]

Retried this test url with today's build on windows and crashed after I pressed 
BACK button(applets loaded fine,build 2000081608m18). Resummarizing and 
changing back OS:ALL.

Comment 38

[edburns]

The ALIGN part of this bug is fixed.  The Applet Lifecycle part of this bug is 
not.  Please see bug 31220.

Comment 39

[shrirang khanzode]

marking veriifed since the original problem in this bug is fixed (align tag 
crashes browser). Logged bug 50547 for the hang when pressing back button. Also, 
the lifecycle problem is a different bug. so... closing this one.