Closed Bug 825786 Opened 7 years ago Closed 7 years ago
crash in ns
Auto Complete Controller::Handle Delete
Steps to reproduce: - Focus Search box - Press the down arrow key to open up autocomplete popup - Press again the down arrow key to select the first autocomplete entry - Press and hold the del key to continuously delete items - While doing that, click on the minimize button of the Firefox window. Result: crash Note that I have a lot of autocomplete entries in my search history. That might be necessary to trigger this crash. This bug was filed from the Socorro interface and is report bp-ff49af59-e377-415f-9af4-c2f992130101 . ============================================================= 0 xul.dll nsAutoCompleteController::HandleDelete toolkit/components/autocomplete/nsAutoCompleteController.cpp:571 1 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70 2 xul.dll XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:2383 3 xul.dll XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1469 4 mozjs.dll js::RunScript js/src/jsinterp.cpp:321
we should likely use the local input variable, looks like something earlier in the method may cause mInput to be set to null, that is why we make our own input pointer earlier. I may eventually make a patch and generate a trybuild for you to test.
Assignee: nobody → mak77
Status: NEW → ASSIGNED
Marco, do you have a patch?
no, but I will make one today, thanks for the reminder.
I'm not sure I can come with a test, trying. I wanted to send this to Try to give you a build but it's currently closed :(
the only way to make a test would be to have something explicitly setting input to null when called inside handleDelete, that doesn't look like a really good test :( Based on the description, when minimize is hit it's likely there's a blur event, could be some nested loop causes the input to be detached and we are in the middle of handleDelete when it happen... But I was not able to reproduce in debug mode to figure at which point mInput becomes null. I pushed this to try, maybe Martijn can try to reproduce with the try builds.
in the end takes less time to just push this and wait for a nightly, Try was closed and then overcrowded and the fix should be harmless. https://hg.mozilla.org/integration/mozilla-inbound/rev/581b2c43af07
Target Milestone: --- → mozilla21
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Ok, it seems to be fixed, thanks. I tried in a 20130101 nightly build, and I immediately got the crash. Then I tried 2 times with a 20130117 nightly build, and I didn't get the crash.
Status: RESOLVED → VERIFIED
That's great, thank you Martijn
You need to log in before you can comment on or make changes to this bug.