Closed Bug 13007 Opened 25 years ago Closed 24 years ago

hitting tab in the password dialog causes an assert (used to crash!).

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: joki)

References

Details

(Keywords: crash) 

in mail news, we use the nsIPrompt password dialog to get the users mail news
password.

I'm sure other places use the same password dialog, and will see the same crash.

on linux, if I start typing my password, and then hit tab (expecting focus to
move the OK button) it crashes.

here's the stack trace:

#0  0x40bbf8bc in nsEventStateManager::PreHandleEvent (this=0x92395e8,
aPresContext=@0x91c8ee8, aEvent=0xbfffe93c, aTargetFrame=0x0,
aStatus=@0xbfffe8c8, aView=0x9242980) at nsEventStateManager.cpp:111
#1  0x40c0153e in PresShell::HandleEvent (this=0x89573b8, aView=0x9242980,
aEvent=0xbfffe93c, aEventStatus=@0xbfffe8c8) at nsPresShell.cpp:1945
#2  0x4226cb43 in nsView::HandleEvent (this=0x9242980, event=0xbfffe93c,
aEventFlags=8, aStatus=@0xbfffe8c8, aHandled=@0xbfffe86c) at nsView.cpp:834
#3  0x4226cad2 in nsView::HandleEvent (this=0x919d878, event=0xbfffe93c,
aEventFlags=28, aStatus=@0xbfffe8c8, aHandled=@0xbfffe86c) at nsView.cpp:818
#4  0x42275e53 in nsViewManager::DispatchEvent (this=0x8992a30,
aEvent=0xbfffe93c, aStatus=@0xbfffe8c8) at nsViewManager.cpp:1574
#5  0x4226ac64 in HandleEvent (aEvent=0xbfffe93c) at nsView.cpp:66
#6  0x417a45c2 in nsWidget::DispatchEvent (this=0x9242a00, event=0xbfffe93c,
aStatus=@0xbfffe904) at nsWidget.cpp:1199
#7  0x417a42ec in nsWidget::DispatchWindowEvent (this=0x9242a00,
event=0xbfffe93c) at nsWidget.cpp:1065
#8  0x417a7eb8 in nsWindow::OnKey (this=0x9242a00, aEvent=@0xbfffe93c) at
nsWindow.cpp:525
#9  0x417975a6 in handle_key_press_event (w=0x9242ad8, event=0x88a5400,
p=0x9242a00) at nsGtkEventHandler.cpp:608
#10 0x4087e79d in gtk_marshal_BOOL__POINTER ()
#11 0x40846037 in gtk_handlers_run ()
#12 0x4084565f in gtk_signal_real_emit ()
#13 0x40843800 in gtk_signal_emit ()
#14 0x408765b8 in gtk_widget_event ()
#15 0x4087d384 in gtk_window_key_press_event ()
#16 0x4087e79d in gtk_marshal_BOOL__POINTER ()
#17 0x40845568 in gtk_signal_real_emit ()
#18 0x40843800 in gtk_signal_emit ()
#19 0x408765b8 in gtk_widget_event ()
#20 0x4081b126 in gtk_propagate_event ()
#21 0x4081a4da in gtk_main_do_event ()
#22 0x408bdab2 in ?? () from /usr/lib/libgdk-1.2.so.0
#23 0x408ea2c6 in g_main_dispatch ()
#24 0x408ea801 in g_main_iterate ()
#25 0x408ea8a3 in g_main_iteration ()
#26 0x417912c7 in nsAppShell::GetNativeEvent (this=0x91e49d0,
aRealEvent=@0xbffff17c, aEvent=@0xbffff180) at nsAppShell.cpp:418
#27 0x4171a06a in nsWebShellWindow::ShowModalInternal (this=0x9155d88) at
nsWebShellWindow.cpp:1777
#28 0x41719f61 in nsWebShellWindow::ShowModal (this=0x9155d88) at
nsWebShellWindow.cpp:1749
#29 0x4171a27b in nsWebShellWindow::ShowModally (this=0x9155d88, aPrepare=0) at
nsWebShellWindow.cpp:1811
#30 0x40f6da7e in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libjsdom.so
#31 0x40f6d294 in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libjsdom.so
#32 0x41729b89 in nsCommonDialogs::DoDialog (this=0x919d868, inParent=0x8283780,
ioParamBlock=0x8a34ff8, inChromeURL=0x41735420
"chrome://global/content/commonDialog.xul") at nsCommonDialogs.cpp:289
#33 0x41729956 in nsCommonDialogs::PromptPassword (this=0x919d868,
inParent=0x8283780, inMsg=0x919d020, outPassword=0xbffff644, _retval=0xbffff640)
at nsCommonDialogs.cpp:250
#34 0x417239c5 in nsNetSupportDialog::PromptPassword (this=0x919d630,
text=0x919d020, pwd=0xbffff644, returnValue=0xbffff640) at
nsNetSupportDialog.cpp:589
#35 0x413bc55d in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libmsgbaseutil.so
#36 0x4165757d in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/components/libmsgimap.so
#37 0x4015416c in XPTC_InvokeByIndex (that=0x8aa97f0, methodIndex=7,
paramCount=1, params=0x9119b38) at xptcinvoke_unixish_x86.cpp:160
#38 0x4014ac6c in EventHandler (self=0x9197d10) at nsProxyEvent.cpp:434
#39 0x4017e29b in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libplds3.so
#40 0x4017e1ac in ?? () from
/builds/seth/MOZILLA/07.28.1999/19.52/mozilla/dist/bin/libplds3.so
#41 0x4014734d in nsEventQueueImpl::ProcessPendingEvents (this=0x8072fd0) at
nsEventQueue.cpp:118
#42 0x417909de in event_processor_callback (data=0x8072fd0, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:149
#43 0x408bc789 in ?? () from /usr/lib/libgdk-1.2.so.0
#44 0x408e8d6a in g_io_unix_dispatch ()
#45 0x408ea2c6 in g_main_dispatch ()
#46 0x408ea801 in g_main_iterate ()
#47 0x408ea979 in g_main_run ()
#48 0x40819f3a in gtk_main ()
#49 0x417911b9 in nsAppShell::Run (this=0x80ae7f8) at nsAppShell.cpp:371
#50 0x417134f1 in nsAppShellService::Run (this=0x80addd0) at
nsAppShellService.cpp:450
#51 0x804b0f8 in main1 (argc=2, argv=0xbffff9f4) at nsAppRunner.cpp:829
#52 0x804b205 in main (argc=2, argv=0xbffff9f4) at nsAppRunner.cpp:852
#53 0x4027ccb3 in ?? () from /lib/libc.so.6
Summary: hitting tab in the password dialog causes a crash. → hitting tab in the password dialog causes an assert (used to crash!).
I've checked in a patch that prevents the crash, and makes it just assert.
see mozilla/layout/events/src/nsEventStateManager.cpp, approx line 111

Now, we don't crash.  we just assert, and lose focus.

I've also checked in a bit of bullet proofing so that if aEvent is null, we
won't crash.

asserting is better than crashing anyday.

changing bug summary to reflect it asserts instead of crashes.

Here's the assertion now:

Assertion: "mCurrentTarget is null.  this should not happen.  see bug #13007"
(mCurrentTarget) at file nsEventStateManager.cpp, line 112
Assignee: troy → joki
Component: Layout → Event Handling
*** Bug 13205 has been marked as a duplicate of this bug. ***
*** Bug 13205 has been marked as a duplicate of this bug. ***
I'm not sure why I got assigned this report. I'm qa for layout not event
handling. Seth, could you please mark this as verified ?
QA Contact: petersen → sspitzer
petersen, I don't think this bug is fixed yet.  can't verify until then.

but I'll make myself the QA contact if you like.

I just tested it, and I'm not getting the assertion any more, but I'll leave it
to joki to decide if it's fixed or not.
fyi, I've encountered this assertion after hitting tab when entering an URL
Blocks: uaag
Adding "crash" keyword to all known open crasher bugs.
Keywords: crash
I keep hitting this assert still in debug builds, is this a symptom of a deeper 
problem? its annoying when debugging because if you hit it once, you get a 
shower of them which keeps debug breaking. I need to remove the assertion almost 
every time. 
This bug also shows up in a more serious fashion if I add an onkeypress= handler 
in a checkbox. I hit a crash in nsEventStateManager::PostHandleEvent since 
mCurrentTarget is null. I can work around it by adding the same if 
mCurrentTarget == null then return failure code as in PreHandleEvent. 

The app seems to work fine with these. Is this assertion spurious, if so we need 
to remove it. In any case, we need to add the above return case to 
PostHandleEvent. Can you do so? 

IS returning early in these cases masking some serious problem?

My bugsplat 383498 is depending on this!

Thanks, Vishy

Doesn't crash or assert on WINNT with build from 4/1/2000.
Will try Linux next.
I'm seeing this some times when I reply to a message, and start typing when the 
cursor is placed at the top.

here's the stack:

nsDebug::Assertion(const char * 0x01f052b4, const char * 0x01f052a4, const char 
* 0x01f05264, int 386) line 189 + 13 bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x045ef7f0, 
nsIPresContext * 0x03282590, nsGUIEvent * 0x0012faf4, nsIFrame * 0x00000000, 
nsEventStatus * 0x0012fa5c, nsIView * 0x0328bac0) line 386 + 35 bytes
PresShell::HandleEvent(PresShell * const 0x0328c434, nsIView * 0x0328bac0, 
nsGUIEvent * 0x0012faf4, nsEventStatus * 0x0012fa5c) line 3005 + 43 bytes
nsView::HandleEvent(nsView * const 0x0328bac0, nsGUIEvent * 0x0012faf4, unsigned 
int 28, nsEventStatus * 0x0012fa5c, int & 0) line 799
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x0328a1e0, nsGUIEvent * 
0x0012faf4, nsEventStatus * 0x0012fa5c) line 1216
HandleEvent(nsGUIEvent * 0x0012faf4) line 69
nsWindow::DispatchEvent(nsWindow * const 0x0328c9f4, nsGUIEvent * 0x0012faf4, 
nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012faf4) line 514
nsWindow::DispatchKeyEvent(unsigned int 133, unsigned short 0, unsigned int 89) 
line 1907 + 15 bytes
nsWindow::OnKeyDown(unsigned int 89, unsigned int 21) line 1936 + 25 bytes
nsWindow::ProcessMessage(unsigned int 256, unsigned int 89, long 1376257, long * 
0x0012fd94) line 2223 + 32 bytes
nsWindow::WindowProc(HWND__ * 0x00190528, unsigned int 256, unsigned int 89, 
long 1376257) line 671 + 27 bytes
USER32! 77e71820()
00150001()

I see this assert a gazillion times using AIM on Mac.

I'm seeing this same stack trace now when trying to delete messages in the
thread pane. What's worse is once I hit this assertion in response to deleting a
message, I get in an infinite loop of these assertions. It keeps getting called
over and over again.

Here's the current stack trace:
nsDebug::Assertion(const char * 0x0224d74c, const char * 0x0224d73c, const char
* 0x0224d700, int 246) line 191 + 13 bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x0318b060,
nsIPresContext * 0x0290bcc0, nsGUIEvent * 0x0012fac0, nsIFrame * 0x00000000,
nsEventStatus * 0x0012fa28, nsIView * 0x0184c320) line 246 + 35 bytes
PresShell::HandleEvent(PresShell * const 0x02447774, nsIView * 0x0184c320,
nsGUIEvent * 0x0012fac0, nsEventStatus * 0x0012fa28, int & 1) line 3459 + 43 bytes
nsView::HandleEvent(nsView * const 0x0184c320, nsGUIEvent * 0x0012fac0, unsigned
int 28, nsEventStatus * 0x0012fa28, int & 1) line 811
nsViewManager::DispatchEvent(nsViewManager * const 0x0184a190, nsGUIEvent *
0x0012fac0, nsEventStatus * 0x0012fa28) line 1765
HandleEvent(nsGUIEvent * 0x0012fac0) line 69
nsWindow::DispatchEvent(nsWindow * const 0x0184f044, nsGUIEvent * 0x0012fac0,
nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fac0) line 519
nsWindow::DispatchKeyEvent(unsigned int 133, unsigned short 0, unsigned int 17)
line 1917 + 15 bytes
nsWindow::OnKeyDown(unsigned int 17, unsigned int 29) line 1946 + 25 bytes
nsWindow::ProcessMessage(unsigned int 256, unsigned int 17, long 1900545, long *
0x0012fd94) line 2285 + 32 bytes
nsWindow::WindowProc(HWND__ * 0x001204aa, unsigned int 256, unsigned int 17,
long 1900545) line 676 + 27 bytes

Bumping the severity of the bug. It'd be great if we could get a milestone
target on this too. It's really hard to use mail right now on debug builds
because of this assertion.
Severity: normal → critical
I'm noticing this under Linux with nightly builds.

I enter my username, hit tab in attempt to get to password box, and it crashes.



I notice this on various forms on the internet in addition to webmail types.


This should be fixed now


I just tested this on the latest win32 build and the assert no longer fires when 
I hit tab in the mail password text box.  Marking this fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
No asserts for me on win2k with a debug build, either.
Status: RESOLVED → VERIFIED
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.