If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED FIXED

Status

()

Toolkit
Form Manager
--
blocker
RESOLVED FIXED
14 years ago
6 years ago

People

(Reporter: Scott Field, Assigned: jst)

Tracking

(4 keywords)

Trunk
crash, fixed-aviary1.0, fixed1.7.5, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: http://test.mozilla.org/testrunner/test.cgi?run_id=212#26, crash signature, URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
You don't even have to select field and click ok.  Opening the forms manager
then clicking cancel will also cause it to crash

Comment 2

14 years ago
Created attachment 152799 [details]
Stack trace (Linux)

Comment 3

14 years ago
(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]

Comment 4

14 years ago
This is similar to bug 5937923 with 1.8a2 in Windows.

Updated

14 years ago
Summary: When using autofill Mozilla crashes [@ GlobalWindowImpl::Close] → When using autofill Mozilla crashes [@ GlobalWindowImpl::Close]

Comment 5

14 years ago
crash, Talkback ID: TB304391W
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a2) Gecko/20040705
Whiteboard: TB304391W

Updated

14 years ago
Keywords: talkbackid

Comment 6

13 years ago
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

Comment 7

13 years ago
This is a smoketest blocker. Does anyone know on which date it started?

bug 250511 may also be related. 
Severity: critical → blocker
Keywords: smoketest

Updated

13 years ago
Whiteboard: http://test.mozilla.org/testrunner/test.cgi?run_id=212#26

Comment 8

13 years ago
Bug 250511 has oldest build date - 20040706.

Comment 9

13 years ago
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.

Comment 10

13 years ago
OK. I'm trying to track down a regregression window that's a bit smaller. update
coming soon.

Comment 11

13 years ago
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

Comment 12

13 years ago
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
(Assignee)

Comment 14

13 years ago
Created attachment 153077 [details] [diff] [review]
Fix. Ignore close() calls on windows that are already closed, like we used to.
(Assignee)

Updated

13 years ago
Attachment #153077 - Flags: superreview?(brendan)
Attachment #153077 - Flags: review?(dveditz)
(Assignee)

Comment 15

13 years ago
*** Bug 250511 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 16

13 years ago
*** Bug 250880 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
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+

Updated

13 years ago
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
(Assignee)

Comment 20

13 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 13 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

Updated

13 years ago
Depends on: 248870
Hello, we need this on 1.7 branch as well. No Aviary/1.7 Geck divergence please.

Updated

13 years ago
Flags: blocking-aviary1.0PR?
(Reporter)

Comment 22

13 years ago
Crash is occuring again with 1.8a3 2004083008  with Mac OS X 10.3.5
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 23

13 years ago
ScottF4@maclaunch.com: could you provide a talkback id or stack trace?

Comment 24

13 years ago
Wint recient build I experienced the problem again here is the incident report
TB720887Z

Comment 25

13 years ago
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.
(Reporter)

Comment 26

13 years ago
Talkback id's TB714827K & TB718592Z

Comment 27

13 years ago
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?
(Reporter)

Comment 28

13 years ago
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
(Reporter)

Comment 29

13 years ago
Note:  Bug is dupe of 257825

Comment 30

13 years ago
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.

Updated

13 years ago
Flags: blocking-aviary1.0PR?
(Assignee)

Comment 31

13 years ago
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
Last Resolved: 13 years ago13 years ago
Resolution: --- → FIXED

Updated

13 years ago
Flags: blocking-aviary1.0PR?
(Assignee)

Comment 32

13 years ago
Fixed in 1.7.x
Keywords: fixed1.7.x

Updated

9 years ago
Component: Form Manager → Form Manager
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.