78422 - crash after viewing xul source [@ nsEventStateManager::PreHandleEvent]

Status: RESOLVED WORKSFORME

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

Description

[mcalisk]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    20001010

If I open a XUL template then right-click on the screen and choose view source, 
then close that window I get a an error and the program crashes. The error 
says "The instruction at "0X00000" referenced memory at "0X000000". The memory 
could not be read"

Reproducible: Always
Steps to Reproduce:
1.Open a XUL Template.
2.Choose view page source.
3.Close the source page.

Actual Results:  Mozilla crashes.

Expected Results:  The window should close, and I should be able to contunue 
using Mozilla.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I see this on a linux debug build from 2001-05-01

Steps to reproduce:

1) Load chrome://communicator/content/pref/pref-appearance.xul
2) right-click and select view source.
3) click in the resulting window (closing does not cause a crash for me on Linux)

#0  0x414dd138 in nsEventStateManager::PreHandleEvent (this=0x89ebf78, 
    aPresContext=0x88b8d20, aEvent=0xbfffe668, aTargetFrame=0x89eb570, 
    aStatus=0xbfffe594, aView=0x89dbb68) at nsEventStateManager.cpp:483
#1  0x41d6056f in PresShell::HandleEventInternal (this=0x89e6778,
aEvent=0xbfffe668, 
    aView=0x89dbb68, aFlags=1, aStatus=0xbfffe594) at nsPresShell.cpp:5545
#2  0x41d60178 in PresShell::HandleEvent (this=0x89e6778, aView=0x89dbb68, 
    aEvent=0xbfffe668, aEventStatus=0xbfffe594, aForceHandle=0,
aHandled=@0xbfffe538)
    at nsPresShell.cpp:5478

(gdb) frame 0
#0  0x414dd138 in nsEventStateManager::PreHandleEvent (this=0x89ebf78, 
    aPresContext=0x88b8d20, aEvent=0xbfffe668, aTargetFrame=0x89eb570, 
    aStatus=0xbfffe594, aView=0x89dbb68) at nsEventStateManager.cpp:483
483           win->GetRootFocusController(getter_AddRefs(focusController));
(gdb) p win
$1 = {mRawPtr = 0x0}
(gdb) p globalObj
$2 = {mRawPtr = 0x0}

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: full stack trace

Comment 3

[Madhur Bhatia]

QA contact updated

Comment 4

[joki (gone)]

I'm not able to reproduce this on Win2K.  The source page comes up blank for me 
and nothing happens when I click.  I'm not sure if the blank source is another 
bug (do we treat xul source differently?) but I don't see an event problem.  Is 
this still happening on linux?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Looks like something has broken the viewing of XUL page source in general (at
least for some XUL docs).

Comment 6

[joki (gone)]

Moving to 0.9.3.  Created new bug for not being able to view-source on xul and 
set it as dependency.

Comment 7

[Blake Ross]

Missed 0.9.3.

Comment 8

[saari (gone)]

->0.9.5

Comment 9

[saari (gone)]

-> 0.9.6

Comment 10

[Jonadab the Unsightly One (Nathan Eady)]

Looks like this won't make it in for 0.9.6.

Comment 11

[joki (gone)]

0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly

Comment 12

[joki (gone)]

Moving bugs from 0.9.7 for triaging in 0.9.8

Comment 13

[Peter Trudelle]

->moz1.1 (dumping ground) per ADT triage

Comment 14

[Adam Hauner]

BTW bug 101834 has same stack signature.

Comment 15

[Pham]

http://bugzilla.mozilla.org/show_bug.cgi?id=179125#c3

joki is no longer here

Comment 16

[Vedran Miletic]

retargeting

Comment 17

[Wayne Mery (:wsmwk)]

bz

attempted to find matching stacks on talkback
nsEventStateManager::PreHandleEvent doesn't fall in top 500 of talkback, so selected a 10 random crashes of 100 that don't have comments ... no crashes containing nsWidget.  (nsWidget is near top of stack trace for this bug - but of course might not be part of the process leading up to every crash)

9 crashes on crash-stats, none contain nsWidget

reporter email address is dead