Closed Bug 29882 Opened 25 years ago Closed 24 years ago

holding down arrow keys to navigate categories crashes browser

Categories

(SeaMonkey :: Preferences, defect, P1)

Product:
SeaMonkey
Component:
Preferences
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: matt)

References

Details

(Keywords: crash, Whiteboard: [nsbeta2+]) 

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
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).
Keywords: beta1, crash
PDT- edge case
Whiteboard: [PDT-]
*** Bug 30475 has been marked as a duplicate of this bug. ***
Clicking on different categories quickly will cause a similar crash.
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?
Whiteboard: [PDT-]
PDT-
Whiteboard: [PDT-]
see bug 30477 for the same stack trace, if that's relevant
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?
Depends on: 30477
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.
Status: NEW → ASSIGNED
Target Milestone: M15
I see that assertion quite often, but it's usually harmless. I think it's 
Waterson's.
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).
I'm trying it on the tip and it's not crashing for me anymore
*** Bug 34536 has been marked as a duplicate of this bug. ***
This is not crashing for me anymore either.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Target Milestone: M15 → ---
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.
yeah, the arrow keys no longer work! (bug 34900)

so, am gonna reopen this puppy, till the arrow keys are functional again. :-)
Status: RESOLVED → REOPENED
Depends on: 34900
No longer depends on: 30477
Resolution: WORKSFORME → ---
Well, that explains why I couldn't reproduce it. :-)

Matt, who should really get this bug?
Priority: P3 → P1
Target Milestone: --- → M16
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 ...
Target Milestone: M16 → M17
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.
This should be actually fixed before it gets too difficult to reproduce on fast 
computers.
pardon the spam: beta1 is long gone...removing this keyword. will soon replace
w/nsbeta2...
Keywords: beta1
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.
Keywords: nsbeta2
Whiteboard: [PDT-]
Putting on [nsbeta2+] radar to fix the crash.
Whiteboard: [nsbeta2+]
Move to M18 target milestone.
Target Milestone: M17 → M18
I've been arrowing around for the last ten minutes on today's build (7/6) and
see no problem.  Marking worksforme.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
I've been arrowing around for the last ten minutes on today's build (7/6) and
see no problem.  Marking worksforme.
Resolution: WORKSFORME → ---
verified worksforme (no crash win32/mac/linux while arrowing through prefs 
tree).
Status: RESOLVED → VERIFIED
This was fixed the week before last with 
a check into the tree but it still throughs an
exeption on the debug builds.
this bug is still "verified" even though the resolution was cleared?
mid-air collision ? / bugzilla cleanup
Reopening (current State: verfied and no resolution)
Status: VERIFIED → REOPENED
marking fixed
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
verified
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.