Closed Bug 229908 Opened 22 years ago Closed 22 years ago

Mozilla locks up when you press the TAB key while filling out a form at 1800flowers.com [@ nsJSContext::DOMBranchCallback] [@ NTDLL.DLL]

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: repoman, Unassigned)

References

()

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 at Http://www.1800flowers.com after you've selected something to buy and filled out the recipient's Name, Street Address, and press TAB after selecting your city, Mozilla will lock up (can only be shut down by ctrl+alt+delete and the window maximize button gets disabled.) Reproducible: Always Steps to Reproduce: a) go to Http://www.1800flowers.com b) click on a "BUY NOW" item. c) type in your state and zip code. d) choose a delivery date e) Click "Add to Cart" button. f) When the next page loads up, Click "No Thanks, continue" button g) When the next page loads up, Click "Checkout Now" button h) Under location type select "Residential" i) Enter your Name, Street Address, j) When you get to "Enter City" click the pulldown arrow and select the only city listed. k. Now press the tab key. j. Now scream because it took all that work and mozilla crashed. Actual Results: Mozilla locks up (cannot be closed by clicking the [X] button. All Mozilla windows freeze up. Mozilla's Maximize window button gets disabled too. Expected Results: Mozilla should have just jumped to the next text entry box, like it does on every other webpage.
Keywords: qawanted
this looks somewhat like Bug 229520; i hang first and then after waiting some seconds (i guess about 30?!) Mozilla crashes with an access vialation in NTDLL.dll. the "problem" is, when i debug Mozilla while it's hanging i get very different callstacks every time, so Mozilla seems to do something; anyway some sample callstack when Mozilla finally crashes: NTDLL! 77893658() NTDLL! 778b55eb() NTDLL! 778a7c5e() NTDLL! 778cb167() MSVCRT! 78001532() MSVCRT! 780014cf() JS3250! js_InflateString + 23 bytes JS3250! JS_NewStringCopyZ + 58 bytes XPC3250! XPCConvert::NativeData2JS(class XPCCallContext &,long *,void const *,class nsXPTType const &,struct nsID const *,struct JSObject *,unsigned int *) + 1163 bytes XPC3250! nsXPCWrappedJSClass::CallMethod(class nsXPCWrappedJS *,unsigned short,class nsXPTMethodInfo const *,struct nsXPTCMiniVariant *) + 2225 bytes XPC3250! nsXPCWrappedJS::CallMethod(unsigned short,class nsXPTMethodInfo const *,struct nsXPTCMiniVariant *) + 63 bytes XPCOM! nsXPTCStubBase::Stub3(void) + 909 bytes XPCOM! nsXPTCStubBase::Stub3(void) + 38 bytes GKLAYOUT! nsXULControllers::GetControllerForCommand(char const *,class nsIController * *) + 194 bytes JSDOM! nsFocusController::GetControllerForCommand(char const *,class nsIController * *) + 797 bytes GKLAYOUT! nsXULCommandDispatcher::GetControllerForCommand(char const *,class nsIController * *) + 37 bytes XPCOM! XPTC_InvokeByIndex + 39 bytes XPC3250! XPCWrappedNative::CallMethod(class XPCCallContext &,enum XPCWrappedNative::CallMode) + 3875 bytes XPC3250! XPC_WN_CallMethod(struct JSContext *,struct JSObject *,unsigned int,long *,long *) + 305 bytes JS3250! js_Invoke + 2557 bytes JS3250! js_Interpret + 43406 bytes JS3250! js_Invoke + 2653 bytes JS3250! js_InternalInvoke + 225 bytes JS3250! JS_CallFunctionValue + 34 bytes JSDOM! nsJSContext::CallEventHandler(void *,void *,unsigned int,void *,int *) + 367 bytes JSDOM! nsJSEventListener::HandleEvent(class nsIDOMEvent *) + 1859 bytes GKLAYOUT! nsEventListenerManager::HandleEventSubType(struct nsListenerStruct *,class nsIDOMEvent *,class nsIDOMEventTarget *,unsigned int,unsigned int) + 690 bytes GKLAYOUT! nsEventListenerManager::HandleEvent(class nsIPresContext *,struct nsEvent *,class nsIDOMEvent * *,class nsIDOMEventTarget *,unsigned int,enum nsEventStatus *) + 749 bytes GKLAYOUT! nsXULElement::HandleDOMEvent(class nsIPresContext *,struct nsEvent *,class nsIDOMEvent * *,unsigned int,enum nsEventStatus *) + 3429 bytes GKLAYOUT! nsXULCommandDispatcher::UpdateCommands(class nsAString const &) + 866 bytes JSDOM! GlobalWindowImpl::UpdateCommands(class nsAString const &) + 286 bytes JSDOM! nsFocusController::UpdateCommands(class nsAString const &) + 54 bytes JSDOM! nsFocusController::SetFocusedElement(class nsIDOMElement *) + 115 bytes
ok i got the stacktrace via a debug build confirming, since i can't find a dupe by now per stacktrace and some search in Bugzilla stacktrace has been attached
Assignee: general → general
Status: UNCONFIRMED → NEW
Component: Browser-General → DOM
Ever confirmed: true
QA Contact: general → ian
Attached file Stacktrace
this stacktrace has been produced on win2k with a current cvs trunk debug build; notice in opt builds with symbols it always crashes in ntdll.dll
Summary: Mozilla locks up when you press the TAB key while filling out a form at 1800flowers.com → Mozilla locks up when you press the TAB key while filling out a form at 1800flowers.com [@nsJSContext::DOMBranchCallback] [@NTDLL.DLL]
Keywords: qawanted
Reporter: Do you still see this bug with a current Mozilla nightly (or Mozilla 1.6)? This bug seems to be gone for me.
Using the steps to reproduce I was unable to crash using Mozilla 1.7 beta. Looks like this crash is no longer an issue. Marking worksforme. If anyone is able to reproduce this bug, please reopen and include a Talkback ID. Thanks.
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: crash
Resolution: --- → WORKSFORME
Summary: Mozilla locks up when you press the TAB key while filling out a form at 1800flowers.com [@nsJSContext::DOMBranchCallback] [@NTDLL.DLL] → Mozilla locks up when you press the TAB key while filling out a form at 1800flowers.com [@ nsJSContext::DOMBranchCallback] [@ NTDLL.DLL]
Crash Signature: [@ nsJSContext::DOMBranchCallback] [@ NTDLL.DLL]
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: