Closed Bug 250771 Opened 20 years ago Closed 20 years ago

When using autofill Mozilla crashes [@ GlobalWindowImpl::Close]

Categories

(Toolkit :: Form Manager, defect)

Product:
Toolkit
Component:
Form Manager
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: ScottF4+bugzilla, Assigned: jst)

References

(
URL
)

Details

(4 keywords, Whiteboard: http://test.mozilla.org/testrunner/test.cgi?run_id=212#26)

Crash Data

Attachments

(2 files)

Stack trace (Linux)
9.62 KB, text/plain
Details
Fix. Ignore close() calls on windows that are already closed, like we used to.
1.02 KB, patch
dveditz
: review+
dveditz
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040708
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a2) Gecko/20040708

Mac OS X 10.3.4  Mozilla 1.8a2 build 2004070808
This has started happening with the past few builds.
When using auto fill after selecting fields and text and clicking OK, Moz crashes.



Reproducible: Always
Steps to Reproduce:
1.  Go to a site with a form  eg
http://bugzilla.mozilla.org/enter_bug.cgi?format=guided

2.  From edit menu select "Fill in Form"

3.  In form window select fields to use and the text for the fields
4.  Click ok
Actual Results:  
Mozilla crashes

Expected Results:  
Form should have been filled in
You don't even have to select field and click ok.  Opening the forms manager
then clicking cancel will also cause it to crash
(gdb) frame 7
#7  0x414bfc80 in GlobalWindowImpl::Close() (this=0x8119d60) at
nsGlobalWindow.cpp:3519
3519      mDocShell->GetContentViewer(getter_AddRefs(cv));
(gdb) p mDocShell
$19 = (nsIDocShell *) 0x0
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
OS: MacOS X → All
Hardware: Macintosh → All
Summary: When using autofill Mozilla crashes → When using autofill Mozilla crashes [@ GlobalWindowImpl::Close]
This is similar to bug 5937923 with 1.8a2 in Windows.
Summary: When using autofill Mozilla crashes [@ GlobalWindowImpl::Close] → When using autofill Mozilla crashes [@ GlobalWindowImpl::Close]
crash, Talkback ID: TB304391W
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040705
Whiteboard: TB304391W
Keywords: talkbackid
TB304391W: 
GlobalWindowImpl::Close 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 3520]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2030]
XPC_WN_CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1288]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1283]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3376]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1302]
js_InternalInvoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1379]
JS_CallFunctionValue 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
3633]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1356]
GlobalWindowImpl::RunTimeout 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5042]
GlobalWindowImpl::TimerCallback 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 5401]
nsTimerImpl::Fire 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 384]
nsAppShell::GetNativeEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsAppShell.cpp,
line 197]
nsXULWindow::ShowModal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsXULWindow.cpp,
line 380]
nsContentTreeOwner::ShowAsModal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp,
line 467]
nsWindowWatcher::OpenWindowJS 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp,
line 787]
GlobalWindowImpl::OpenInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 4667]
GlobalWindowImpl::OpenDialog 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 3405]
XPTC_InvokeByIndex 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2030]
XPC_WN_CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1288]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1283]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3376]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1302]
js_InternalInvoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1379]
JS_CallFunctionValue 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
3633]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1356]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 180]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1491]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1568]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2789]
nsXULElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2625]
PresShell::HandleDOMEventWithTarget 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6101]
nsMenuFrame::Execute 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 1632]
nsMenuFrame::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 436]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6071]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5936]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2294]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2034]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1064]
nsWindow::DispatchWindowEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1081]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5222]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5473]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 4015]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1343]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x242e7 (0xbff942e7)
0x00648b56

Bug 250880 has similar stack.
Keywords: talkbackid
Whiteboard: TB304391W
This is a smoketest blocker. Does anyone know on which date it started?

bug 250511 may also be related.
Severity: critical → blocker
Keywords: smoketest
Whiteboard: http://test.mozilla.org/testrunner/test.cgi?run_id=212#26
Bug 250511 has oldest build date - 20040706.
While trying to fix bug 78274 I ran into a crash whose stack resembled this one,
so it's just possible that attachment 151485 [details] [diff] [review] will fix this too.
OK. I'm trying to track down a regregression window that's a bit smaller. update
coming soon.
This regressed between 20040704 and 20040705 builds on the trunk. Hook for that
window looks something like this:
http://bonsai.mozilla.org/cvsquery.cgi&branch=Head&sortby=Date&hours=2&date=explicit&mindate=2004-07-04+08%3A00&maxdate=2004-07-05+9%3A00

Johnny and Aaron, this might be one of you guys.
possible regression from bug 248870? jst says mDocShell might be null if the
window is getting closed twice.
Assignee: dveditz → jst
Attachment #153077 - Flags: superreview?(brendan)
Attachment #153077 - Flags: review?(dveditz)
*** Bug 250511 has been marked as a duplicate of this bug. ***
*** Bug 250880 has been marked as a duplicate of this bug. ***
Comment on attachment 153077 [details] [diff] [review]
Fix. Ignore close() calls on windows that are already closed, like we used to.

a=asa when this has reviews
Attachment #153077 - Flags: approval1.8a2+
Comment on attachment 153077 [details] [diff] [review]
Fix. Ignore close() calls on windows that are already closed, like we used to.

r/sr=dveditz for regression fix

a=drivers for 1.8a2
Attachment #153077 - Flags: superreview?(brendan)
Attachment #153077 - Flags: superreview+
Attachment #153077 - Flags: review?(dveditz)
Attachment #153077 - Flags: review+
Keywords: topcrash
Summary: When using autofill Mozilla crashes [@ GlobalWindowImpl::Close] → When using autofill Mozilla crashes Trunk [@ GlobalWindowImpl::Close]
needed on aviary as well
Flags: blocking-aviary1.0RC1?
Whiteboard: http://test.mozilla.org/testrunner/test.cgi?run_id=212#26 → needed-aviary1.0 http://test.mozilla.org/testrunner/test.cgi?run_id=212#26
Fixed.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: topcrash → fixed-aviary1.0
Resolution: --- → FIXED
Summary: When using autofill Mozilla crashes Trunk [@ GlobalWindowImpl::Close] → When using autofill Mozilla crashes [@ GlobalWindowImpl::Close]
Whiteboard: needed-aviary1.0 http://test.mozilla.org/testrunner/test.cgi?run_id=212#26 → http://test.mozilla.org/testrunner/test.cgi?run_id=212#26
Depends on: 248870
Hello, we need this on 1.7 branch as well. No Aviary/1.7 Geck divergence please.
Flags: blocking-aviary1.0PR?
Crash is occuring again with 1.8a3 2004083008  with Mac OS X 10.3.5
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ScottF4@maclaunch.com: could you provide a talkback id or stack trace?
Wint recient build I experienced the problem again here is the incident report
TB720887Z
DWEINTRAUBSPRINT@EARTHLINK.NET (i wish you'd lowercase your email address...),
you can look up your own talkback reports:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB720887Z

there's no sign of GlobalWindowImpl::Close in that stack, it's a different bug.
Talkback id's TB714827K & TB718592Z
scott: as you can see from
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB718592Z

(you can just tack your tbid onto the end of these urls...) talkback isn't
reporting functions for your build, so i can't really tell whether the crash is
related, can you try some other build? perhaps 1.8a3 itself?
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB733243E

Downloaded latest nightly build of 1.8a3 2004090308
created new profile
went to debug/Form Manager Samples, clicked on Sample 1
Fill in form.  Went to edit menu, selected "Save Form Info"
went to debug/Form Manager Samples, clicked on Sample 2
 Went to edit menu, selected "Fill in Form"
Mozilla crashed
Note:  Bug is dupe of 257825
Can someone give status on this problem? I'd like to take the original 1.7 fix
that broke this, and this fix, but not if we are still broke.
Flags: blocking-aviary1.0PR?
Seems like there are two unrelated crashes here, one was the crash when closing
a window, and that was fixed in this bug, the other one seems to be a crash in
layout code when re-entering some restying code, or what not (from lookint at a
stack I got when following the steps in comment #28). IMO we should take this
fix for 1.7, and hopefully the fix for the other problem too once someone
figures out how to fix that.

IMO this is not a dupe, marking this one FIXED, lets track the other problem in
bug 257825.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED
Flags: blocking-aviary1.0PR?
Fixed in 1.7.x
Keywords: fixed1.7.x
Flags: approval1.8a2+
Product: Core → Toolkit
QA Contact: form.manager
Crash Signature: [@ GlobalWindowImpl::Close]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: