34336 - crash when selecting Composer prefs w/arrow keys

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P1)

Description

[sairuh (rarely reading bugmail)]

occurs on opt comm bits on all platforms:

linux, 2000.04.03.09
macOS, 2000.04.03.10
winNT, 2000.04.03.09

to repro:
1. open Preferences, select IM > Away category.
2. using the down arrow key, tap once to get to the Composer category.

result: seamonkey crashes. talkback is slacking off at the moment, so i've only
the incident number, 7906707, for linux.

Comment 1

[sairuh (rarely reading bugmail)]

stack trace for linux:

nsDSWebProgressListener::OnStatusChange() 
nsDocLoaderImpl::FireOnEndDocumentLoad() 
nsDocLoaderImpl::DocLoaderIsEmpty() 
nsDocLoaderImpl::OnStopRequest() 
nsLoadGroup::RemoveChannel() 
nsCachedChromeChannel::HandleStopLoadEvent() 
PL_HandleEvent() 
PL_ProcessPendingEvents() 
nsEventQueueImpl::ProcessPendingEvents() 
event_processor_callback() 
our_gdk_io_invoke() 
libglib-1.2.so.0 + 0xe52a (0x4060652a) 
libglib-1.2.so.0 + 0xfbe6 (0x40607be6) 
libglib-1.2.so.0 + 0x101a1 (0x406081a1) 
libglib-1.2.so.0 + 0x10341 (0x40608341) 
libgtk-1.2.so.0 + 0x8c209 (0x4052f209) 
nsAppShell::Run() 
nsAppShellService::Run() 
main1() 
main() 
libc.so.6 + 0x181eb (0x402f31eb)

Comment 2

[sairuh (rarely reading bugmail)]

Attachment: MacsBug trace

Comment 3

[don]

M15.

Comment 4

[sairuh (rarely reading bugmail)]

mac talkback incident #7906932:



.__ptr_glue 
nsDocLoaderImpl::FireOnEndDocumentLoad() [nsDocLoader.cpp, line 622] 
nsDocLoaderImpl::DocLoaderIsEmpty() [nsDocLoader.cpp, line 505] 
nsDocLoaderImpl::OnStopRequest() [nsDocLoader.cpp, line 457] 
nsLoadGroup::RemoveChannel() [nsLoadGroup.cpp, line 543] 
nsFileChannel::OnStopRequest() [nsFileChannel.cpp, line 567] 
nsOnStopRequestEvent::HandleEvent() [nsAsyncStreamListener.cpp, line 285] 
nsStreamListenerEvent::HandlePLEvent() [nsAsyncStreamListener.cpp, line 97] 
PL_HandleEvent() [plevent.c, line 563] 
PL_ProcessPendingEvents() [plevent.c, line 508] 
nsEventQueueImpl::ProcessPendingEvents() [nsEventQueue.cpp, line 316] 
nsMacNSPREventQueueHandler::ProcessPLEventQueue() [nsToolkit.cpp, line 132] 
nsMacNSPREventQueueHandler::RepeatAction() [nsToolkit.cpp, line 97] 
Repeater::DoRepeaters() [nsRepeater.cpp, line 119] 
nsMacMessagePump::DispatchEvent() [nsMacMessagePump.cpp, line 365] 
nsAppShell::DispatchNativeEvent() [nsAppShell.cpp, line 223] 
nsXULWindow::ShowModal() [nsXULWindow.cpp, line 326] 
nsWebShellWindow::ShowModal() [nsWebShellWindow.cpp, line 1148] 
nsChromeTreeOwner::ShowModal() [nsChromeTreeOwner.cpp, line 179] 
DOM_DLL + 0x1f2f0 (0x05d754f0) 
DOM_DLL + 0x1a6e0 (0x05d708e0) 
DOM_DLL + 0x1119c (0x05d6739c) 
js_Invoke() [jsinterp.c, line 677] 
js_Interpret() [jsinterp.c, line 2457] 
js_Invoke() [jsinterp.c, line 695] 
js_InternalInvoke() [jsinterp.c, line 767]

Comment 5

[sairuh (rarely reading bugmail)]

side note: the trace for Mac above is similar to the one i got for bug 34387.
related?

...and here's the trace info for winNT (incident #7906526):

nsDSWebProgressListener::OnStatusChange
[d:\builds\seamonkey\mozilla\docshell\base\nsDSWebProgressListener.cpp, line 95] 
nsDocLoaderImpl::FireOnEndDocumentLoad
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 623] 
nsDocLoaderImpl::DocLoaderIsEmpty
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 514] 
nsDocLoaderImpl::OnStopRequest
[d:\builds\seamonkey\mozilla\uriloader\base\nsDocLoader.cpp, line 458] 
nsLoadGroup::RemoveChannel
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsLoadGroup.cpp, line 550] 
nsFileChannel::OnStopRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\file\src\nsFileChannel.cpp, line
572] 
nsOnStopRequestEvent::HandleEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
286] 
nsStreamListenerEvent::HandlePLEvent
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
98] 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 564] 
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c,
line 527] 
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line
1020] 
USER32.dll + 0x1820 (0x77e71820)

Comment 6

[matt]

can you look at this since i'm out
all week.

Comment 7

[Kathleen :Brade]

I can't reproduce this bug with a mozilla build on Mac today.  Can anyone else 
reproduce this?  I'm guessing that the fix for related bugs that day also fixed 
this and would like to resolve this as fixed.

Comment 8

[Kathleen :Brade]

since no one else has commented, resolving this bug as fixed

Comment 9

[sairuh (rarely reading bugmail)]

was unable to check this y'day's builds due to bug 24900, where arrow navigation
in Prefs is broken --that's where this bug cropped up. clarified summary, and
reopening.

Comment 10

[rubydoo123]

24900 is marked as a dup and verified, the bug it was duped against is marked as 
fixed and verified -- that was back on 1/26. If arrow navigation is broken, a 
new bug needs to be opened. In any event, I'm moving this out to M17.

Comment 11

[Sean Richardson]

FWIW, I could generate a crash consistently on WinNT by moving from the Fonts
category to any other before the fonts panel appeared, by clicking on the
other category's name, with an 04-03 nightly binary, and generated a talkback 
incident, but since I couldn't reproduce at all with an 04-4 or 04-05 build, 
I let it drop. 

And my guess is that a typo crept in... bug 34900 is "arrow key no longer work
[in prefs]"... adjusting dependency, that would block testing this bug. 

Comment 12

[Sean Richardson]

This also might be be a DUP of bug 29882, "holding down arrow keys to navigate 
categories crashes browser", already blocked by bug 34900.

Comment 13

[sairuh (rarely reading bugmail)]

oops, good catch, sean. yep, i meant bug 34900.

anyhow, am not sure whether this is the same as 29882, since i only tapped the
arrow key once to move to the Composer category (not holding it down to scroll
through several categories).

btw, i was also unable to repro the crasher for clicking to another category
while the Fonts panel is loading (using today's winNT bits, or even mac or
linux).

Comment 14

[sairuh (rarely reading bugmail)]

no longer see this in today's m15 bits (linux, mac or win). marking as wfm...
will verify using m16 in a bit...

Comment 15

[sairuh (rarely reading bugmail)]

hurm, unable to verify due to bug 36736...

Comment 16

[sairuh (rarely reading bugmail)]

yep, wfm. able to verify now that 36736 is fixed.