124632 - Crash if I use "print preview" and then enter another URL [nsEventListenerManager::HandleEvent]

Status: RESOLVED WORKSFORME

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[m.knoerr]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204
BuildID:    2002020415

I visited http://www.heise.de, used the print preview function, and tried
afterwards to visit cms.tu-bs.de -> Mozilla crashed.

Reproducible: Always
Steps to Reproduce:
1.Visit www.heise.de
2.Click "Print Preview" -> preview appears
3.Click "Print Preview" again -> preview disappears
4.Enter the URL cms.tu-bs.de and hit "Enter"

Actual Results:  Mozilla crashes

Expected Results:  Don't crash.

I'm using a kind of anonymizer (anon.inf.tu-dresden.de). Already reported this
bug via Talkback.

Comment 1

[Karl Johan Kleist]

Reporter: It would be helpful if you entered the "Incident ID" here.

Comment 2

[Karl Johan Kleist]

WFM. Build ID: 2002 02 08 03. Windows 2000. (Note that I did choose "Print Preview"
from the "File" menu, in the absence of a button to click.)

Comment 3

[R.K.Aa.]

no crash with a day old CVS build, Linux.

Comment 4

[Pete Boyd]

WFM [Mozilla 2002020908, Windows 2000] but presumably this needs to be tested
through the anonymizer the reporter mentions using; I don't speak much German so
can't find how to use this anonymizer

Comment 5

[Stefan [:stefanh]]

WFM Mac OS 9.1 build 2002020405 (without anonymizer).

Comment 6

[R.K.Aa.]

Reporter:

1: Do the same steps crash if you do not use the anonymizer?
2: Can you restore the Talkback window when the crash has occured and make a n
ote of the talkback ID here.

(On linux the talkback window minimizes while sending Talkback ID, and exits
right afterwards. In order to see the relevant talkback ID you must restore the
window before it has finished sending the incident report.)

Add comments here on web: http://bugzilla.mozilla.org/show_bug.cgi?id=124632

Comment 7

[m.knoerr]

1. The crash occurs also without the anonymizer
2. Talkback ID is TB2736519W

Comment 8

[m.knoerr]

I refined the steps to reproduce the crash:
1. Visit any site (e.g. cms.tu-bs.de, www.heise.de or www.mozilla.org)
2. Use the "Print Preview" function (via icon or file menu)
3. Use it again -> crash

It seems to depend on cms.tu-bs.de, which uses server side includes (*.shtml). I
know the webmaster of this server and can contact him if necessary.

Comment 9

[m.knoerr]

Oooops, fogot step 4:

4. Visit cms.tu-bs.de -> crash

(mozilla does _not_ crash after step 3). I'll checkout the cvs codebase and try
to reproduce this with a new built.

Comment 10

[m.knoerr]

No crash with a fresh built from cvs. Seems to be fixed.

Comment 11

[R.K.Aa.]

Reopening. This should be resolved as "worksforme" if no exact fix is known.
It may well be a duplicate of something that is fixed though.

Stephen: can you please pull TB2736519W ?

Comment 12

[[e-mail] (gone - use [e-mail] instead)]

0x405d72cc
nsEventListenerManager::HandleEvent()
nsDocument::HandleDOMEvent()
nsEventStateManager::PreHandleEvent()
PresShell::HandleEventInternal()
PresShell::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsView::HandleEvent()
nsViewManager::DispatchEvent()
HandleEvent()
nsWidget::DispatchEvent()
nsWidget::DispatchWindowEvent()
nsWidget::DispatchFocus()
nsWindow::DispatchSetFocusEvent()
nsWindow::SetFocus()
GlobalWindowImpl::Focus()
CheckForFocus()
PresShell::UnsuppressAndInvalidate()
PresShell::ProcessReflowCommands()
HandlePLEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xf3b0 (0x403873b0)
libglib-1.2.so.0 + 0x10c46 (0x40388c46)
libglib-1.2.so.0 + 0x11273 (0x40389273)
libglib-1.2.so.0 + 0x1143c (0x4038943c)
libgtk-1.2.so.0 + 0x9276c (0x402a176c)
nsAppShell::Run()
nsAppShellService::Run()
main1()
main()
libc.so.6 + 0x1d7ee (0x404d67ee) 

Comment 13

[R.K.Aa.]

i can't find the exact stack in any recently fixed bugs.
Changing component, adding to summary.

Comment 14

[R.K.Aa.]

..and resolving as WFM.