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

RESOLVED WORKSFORME

Status

()

P1
critical
RESOLVED WORKSFORME
18 years ago
10 years ago

People

(Reporter: mcalisk, Assigned: saari)

Tracking

({crash})

Trunk
Future
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
Keywords: crash
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}
Assignee: trudelle → joki
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets: XUL → Event Handling
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: jrgm → gerardok
Hardware: PC → All

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.2

Updated

18 years ago
Priority: -- → P1

Comment 3

18 years ago
QA contact updated
QA Contact: gerardok → madhur

Comment 4

18 years ago
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?
Looks like something has broken the viewing of XUL page source in general (at
least for some XUL docs).

Comment 6

18 years ago
Moving to 0.9.3.  Created new bug for not being able to view-source on xul and 
set it as dependency.
Depends on: 87918
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 7

18 years ago
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Comment 8

17 years ago
->0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Comment 9

17 years ago
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Looks like this won't make it in for 0.9.6.

Comment 11

17 years ago
0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly
Target Milestone: mozilla0.9.6 → mozilla0.9.7

Comment 12

17 years ago
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8

Updated

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9

Comment 13

17 years ago
->moz1.1 (dumping ground) per ADT triage
Target Milestone: mozilla0.9.9 → mozilla1.1

Updated

17 years ago
QA Contact: madhur → rakeshmishra

Comment 14

17 years ago
BTW bug 101834 has same stack signature.
Summary: crash after viewing xul source → crash after viewing xul source [@ nsEventStateManager::PreHandleEvent]

Updated

16 years ago
QA Contact: rakeshmishra → trix

Comment 15

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

joki is no longer here
Assignee: joki → saari
Status: ASSIGNED → NEW
QA Contact: trix → ian

Comment 16

15 years ago
retargeting
Target Milestone: mozilla1.1alpha → Future

Comment 17

11 years ago
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

Updated

10 years ago
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsEventStateManager::PreHandleEvent]
You need to log in before you can comment on or make changes to this bug.