29882 - holding down arrow keys to navigate categories crashes browser

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P1)

Description

[sairuh (rarely reading bugmail)]

occurred using this morning's opt bits [2000.03.01.08] on winNT [comm], linux
[comm] and mac [mozilla].

to repro:
1. open Preferences.
2. click on any of the categories to highlight it.
3. hold down either the down or up arrow keys to navigate through the category
tree.

expected: should cycle through each category as it is highlighted.
result: categories are sometimes highlighted, but after holding the key down for
more than few seconds (eg, 5 sec or so), i get a crash. talkback reports are
kinda sparse, but here are links to 'em.

Talkback report for linux:
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=48&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6143850

Talkback report for winNT:
http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=48&cp=2&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=6143504

here's console output from linux; not sure how useful it is (just cycling thru
the displayed prefs), except for the javascript error w/InitSingleEngineList:

Mouse down
*** going to save page data for tag: pref-appearance
*** newURL: chrome://pref/content/pref-fonts.xul
got a request
*** PREF_onpageload('pref-fonts');
*** prefindex = 1; prefvalue = 1
*** prefvalue = true
*** prefindex = 0; prefvalue = 1
*** prefvalue = false
*** id & value: browserUseDocumentFonts1 : true
*** id & value: browserUseDocumentFonts0 : false
*** id & value: browserScreenResolution : 96
null
0 
null
select:font.name.serif.x-western
0 
null
select:font.name.monospace.x-western
*** going to save page data for tag: pref-fonts
*** VALUE=x-western
*** VALUE=14
*** VALUE=charter
*** VALUE=charter
*** VALUE=12
*** newURL: chrome://pref/content/pref-navigator.xul
got a request
*** going to save page data for tag: pref-navigator
*** newURL: chrome://pref/content/pref-smart_browsing.xul
got a request
*** PREF_onpageload('pref-navigator');
*** id & value: undefined : undefined
*** going to save page data for tag: pref-smart_browsing
*** newURL: chrome://pref/content/pref-search.xul
got a request
*** PREF_onpageload('pref-smart_browsing');
*** id & value: browserRelatedEnabled : false
*** id & value: browserRelatedDisabledForDomains : 
*** id & value: browserGoBrowsingEnabled : false
*** going to save page data for tag: pref-search
*** newURL: chrome://messenger/content/pref-mailnews.xul
got a request
*** PREF_onpageload('pref-search');
*** id & value: undefined : undefined
JavaScript Error: ReferenceError: InitSingleEngineList is not defined

*** going to save page data for tag: pref-mailnews
*** newURL: chrome://addressbook/content/pref-addressing.xul
got a request
*** PREF_onpageload('pref-mailnews');
*** id & value: undefined : undefined
*** going to save page data for tag: pref-addressing
*** newURL: chrome://messengercompose/content/pref-messages.xul
got a request
*** PREF_onpageload('pref-addressing');
*** id & value: padCheck : false
*** id & value: dirCheck : false
*** id & value: ldap_2.autoComplete.showDialogForMultipleMatches1 : true
*** id & value: ldap_2.autoComplete.showDialogForMultipleMatches : false
*** id & value: useAddress : false
*** going to save page data for tag: pref-messages
*** newURL: chrome://messenger/content/pref-winsetting.xul
got a request
*** PREF_onpageload('pref-addressing');
*** id & value: padCheck : false
*** id & value: dirCheck : false
*** id & value: ldap_2.autoComplete.showDialogForMultipleMatches1 : true
*** id & value: ldap_2.autoComplete.showDialogForMultipleMatches : false
*** id & value: useAddress : false

Comment 1

[sairuh (rarely reading bugmail)]

nominating for beta1. not a problem on 4.7x on winNT (arrow key nav doesn't seem
to be applicable on mac and linux in 4.7x, methinks).

Comment 2

[Phil Peterson]

PDT- edge case

Comment 3

[Jesse Ruderman]

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

Comment 4

[Jesse Ruderman]

Clicking on different categories quickly will cause a similar crash.

Comment 5

[sairuh (rarely reading bugmail)]

i don't think this should be viewed as an edge case, imho --it's very common to
hold down an arrow key in most forms of navigation anyhow.

paulmac, your thoughts?

Comment 6

[Phil Peterson]

PDT-

Comment 7

[Paul MacQuiddy]

see bug 30477 for the same stack trace, if that's relevant

Comment 8

[sairuh (rarely reading bugmail)]

thx for the tip, paul --as it turns out, the trace for winNT looks identical.

waterson/warren, d'you think this one is depended on bug 30477?

Comment 9

[matt]

I don't have this happen for me all the time.
Very hard for me to reproduce.
I do get an assert here 

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x01296a24, const char * 0x01296a04, const char 
* 0x012969d4, int 4975) line 189 + 13 bytes
nsXULDocument::ExecuteScript(JSObject * 0x00ee5038) line 4975 + 38 bytes
nsXULDocument::LoadScript(nsXULPrototypeScript * 0x022a4050, int * 0x0012d754) 
line 4860 + 15 bytes
nsXULDocument::ResumeWalk() line 4645 + 19 bytes
nsXULDocument::OnStreamComplete(nsXULDocument * const 0x036be344, 
nsIStreamLoader * 0x00000000, nsISupports * 0x00000000, unsigned int 0, unsigned 
int 1015, const char * 0x02147a08) line 4939 + 11 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x03682f84, nsIChannel * 
0x036829b0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 111 + 75 bytes
nsResChannel::OnStopRequest(nsResChannel * const 0x036829b4, nsIChannel * 
0x03682780, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 596 + 53 bytes
nsFileChannel::OnStopRequest(nsFileChannel * const 0x03682784, nsIChannel * 
0x03682400, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 
0x00000000) line 446 + 45 bytes
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x03687670) line 
288
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x03686f20) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x03686f20) line 563 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x02da7e90) line 508 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00860c66, unsigned int 49482, unsigned int 0, 
long 47873680) line 1018 + 9 bytes
USER32! 77e71820()
02da7e90()


Please reverify this crashes for you.

Comment 10

[Warren Harris]

I see that assertion quite often, but it's usually harmless. I think it's 
Waterson's.

Comment 11

[sairuh (rarely reading bugmail)]

easily reproducible on linux and mac using today's beta1 branch bits (opt,
commercial), 2000.03.20.05-nb1b.

strangely enough, cannot repro on winNT (also today's beta1 branch bits (opt,
commercial, 2000.03.20.06-nb1b).

Comment 12

[matt]

I'm trying it on the tip and it's not crashing for me anymore

Comment 13

[sairuh (rarely reading bugmail)]

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

Comment 14

[don]

This is not crashing for me anymore either.

Comment 15

[Jesse Ruderman]

Hmm, on 2000 040610, I can't scroll through the prefs page at all using the 
arrow keys.  I hope that's not the only reason nobody is reproducing this 
anymore.

Comment 16

[sairuh (rarely reading bugmail)]

yeah, the arrow keys no longer work! (bug 34900)

so, am gonna reopen this puppy, till the arrow keys are functional again. :-)

Comment 17

[don]

Well, that explains why I couldn't reproduce it. :-)

Matt, who should really get this bug?

Comment 18

[don]

Looks like Hyatt has moved bug #34900 to M17 so there's not much hope in fixing
this for beta 2.  Moving this one to M17 as well ...

Comment 19

[sairuh (rarely reading bugmail)]

this still happens, although i can scroll (ie, hold down arrow keys) for longer
before the browser crashes (or simply freezes). tested w/today's m15 opt comm
bits.

Comment 20

[Jesse Ruderman]

This should be actually fixed before it gets too difficult to reproduce on fast 
computers.

Comment 21

[sairuh (rarely reading bugmail)]

pardon the spam: beta1 is long gone...removing this keyword. will soon replace
w/nsbeta2...

Comment 22

[sairuh (rarely reading bugmail)]

nominating for beta2. this was passed over for beta1, too. true, the workaround
consists of "hey, just don't do that," but it's all too easy to keep holding
down *any* key when using a keyboard. as Jesse said above, this should be
address soon, before it becomes more "hidden" with faster machines.

Comment 23

[leger]

Putting on [nsbeta2+] radar to fix the crash.

Comment 24

[don]

Move to M18 target milestone.

Comment 25

[Michael La Guardia]

I've been arrowing around for the last ten minutes on today's build (7/6) and
see no problem.  Marking worksforme.

Comment 26

[Michael La Guardia]

I've been arrowing around for the last ten minutes on today's build (7/6) and
see no problem.  Marking worksforme.

Comment 27

[John Morrison]

verified worksforme (no crash win32/mac/linux while arrowing through prefs 
tree).

Comment 28

[matt]

This was fixed the week before last with 
a check into the tree but it still throughs an
exeption on the debug builds.

Comment 29

[Jesse Ruderman]

this bug is still "verified" even though the resolution was cleared?

Comment 30

[Matthias Versen [:Matti]]

mid-air collision ? / bugzilla cleanup
Reopening (current State: verfied and no resolution)

Comment 31

[Matthias Versen [:Matti]]

marking fixed

Comment 32

[Matthias Versen [:Matti]]

verified