Closed Bug 459411 Opened 12 years ago Closed 10 years ago
Crash in [@ ns
Nav History Result::On Clear History() ] when deleting individual history entry
Seen while testing Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1) Gecko/20081007 Firefox/3.1b1. STR: 1. Open the history sidebar. 2. Select an individual history entry. Invoke the context menu and then select delete. 3. Crash, but have not been able to reproduce as of yet. A few other details: JIT was turned on. NoScript and Web of Trust extensions installed. Breakpad: http://crash-stats.mozilla.com/report/index/602ed730-96f8-11dd-9e08-001321b13766
Marcia, this stack is truly bizarre! Clicking down on Delete in the context menu seems to have raised a modal dialog (a Gecko one). Then the crash occurred when (with the modal dialog already displayed) you let go of the mouse button (and a mouse-up event was sent). Do you remember seeing anything like that when the crash happened?
Yes, it seemed as soon as released the mouse button I crashed. I was not able to reproduce during my test session, but I will keep an eye out for it.
But do you remember seeing a modal dialog pop up when you pressed the mouse button?
I did not see a modal dialog pop up. But I hope I am not misremembering the STR - I say that because in my comment I mentioned something about the clear private data dialog :( - if that is the case then I think the stack will make more sense. Let me see if I can find the Litmus test case I was running at the time since it may make more sense.
The two test cases that I ran right in a row were: https://litmus.mozilla.org/show_test.cgi?id=5939 and https://litmus.mozilla.org/show_test.cgi?id=6099. It might have been that I had the sidebar open and I tried to delete the browsing history by using Clear Private Data, but I cannot say for sure.
Marcia, your stack (from comment #0) tells me the following (I think): 1) You chose something from a menu (by clicking the mouse) (-[NativeMenuItemTarget menuItemHit:]). 2) The menu item was invoked (it's action at least began to be performed), presumably while the mouse button was still down (nsMenuItemX::DoCommand). 3) A modal dialog was displayed (or at least began to be displayed, nsXULWindow::ShowModal). It might have been invisible (behind another window, or not yet fully displayed). 4) You let go the mouse button (-[ChildView mouseUp:]). 5) The browser tried to clear all history (nsNavHistory::RemoveAllPages), and then crashed. On the face of it, this doesn't make a whole lot of sense :-) Choosing "Delete" in your first Litmus test should never result in nsNavHistory::RemoveAllPages being called (I just tested this in gdb with the 1.9.1 branch). But nothing in your second Litmus test invokes any menu item (results in -[NativeMenuItemTarget menuItemHit:] being called). I'm going to have to put this aside until we get more information.
this sounds like the clear private data dialog. which also has a keybinding.
(In reply to comment #7) So it does (the key binding for the Clear Private Data dialog (on OS X) is cmd-shift-del). But doing cmd-shift-del doesn't invoke -[NativeMenuItemTarget menuItemHit:], so our mystery remains unsolved.
First 20 frames from Marcia's stack trace: 0 XUL nsNavHistoryResult::OnClearHistory toolkit/components/places/src/nsNavHistoryResult.cpp:4400 1 XUL nsNavHistoryExpire::ClearHistory toolkit/components/places/src/nsNavHistoryExpire.cpp:302 2 XUL nsNavHistory::RemoveAllPages toolkit/components/places/src/nsNavHistory.cpp:4010 3 XUL NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 4 XUL XPCWrappedNative::CallMethod js/src/xpconnect/src/xpcwrappednative.cpp:2405 5 XUL XPC_WN_CallMethod js/src/xpconnect/src/xpcwrappednativejsops.cpp:1477 6 libmozjs.dylib js_Invoke js/src/jsinvoke.cpp:1306 7 libmozjs.dylib js_Interpret js/src/jsinterp.cpp:5001 8 libmozjs.dylib js_Invoke js/src/jsinvoke.cpp:1324 9 XUL nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523 10 XUL nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:565 11 XUL PrepareAndDispatch xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 12 XUL nsXPTCStubBase::Stub3 xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:1 13 XUL nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:1080 14 XUL nsEventListenerManager::HandleEvent content/events/src/nsEventListenerManager.cpp:1185 15 XUL nsEventTargetChainItem::HandleEvent content/events/src/nsEventDispatcher.cpp:211 16 XUL nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:269 17 XUL nsEventDispatcher::Dispatch content/events/src/nsEventDispatcher.cpp:479 18 XUL PresShell::HandleDOMEventWithTarget layout/base/nsPresShell.cpp:5943 19 XUL nsButtonBoxFrame::DoMouseClick layout/xul/base/src/nsButtonBoxFrame.cpp:160 20 XUL nsButtonBoxFrame::HandleEvent layout/xul/base/src/nsButtonBoxFrame.cpp:130 There are a lot of crashes reported for Firefox 3.0.3 with the same top frames. Also seems to happen on Windows. http://crash-stats.mozilla.com/report/list?query_search=signature&query_type=contains&query=nsNavHistoryResult%3A%3AOnClearHistory()&date=&range_value=1&range_unit=weeks&do_query=1&signature=nsNavHistoryResult%3A%3AOnClearHistory() Stacks on Windows are a bit shorter: 0 xul.dll nsNavHistoryResult::OnClearHistory mozilla/toolkit/components/places/src/nsNavHistoryResult.cpp:4396 1 xul.dll nsNavHistoryExpire::ClearHistory mozilla/toolkit/components/places/src/nsNavHistoryExpire.cpp:303 2 xul.dll nsNavHistory::RemoveAllPages mozilla/toolkit/components/places/src/nsNavHistory.cpp:3996 3 xul.dll NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101 4 xul.dll XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393
OS: Mac OS X → All
Hardware: PC → All
Dietrich, somehow related to bug 426275?
are there still reports of this crash on current 3.5? could simply be another case related to bad cycle collecting (bug 487040)
Having the limited search functionality on Socorro I wasn't able to find any crash report of this type in the last weeks, but that doesn't mean anything. It's hard to check for a longer period.
This happened to me in 3.5, but the crash reporter didn't show up :( Also, deleting a bookmark folder with many bookmards (rss feeds) froze Firefox for a few minutes, then everything was fine again.
how can you tell it was this bug? did you see the crash signature with onClearHistory in it? did you get a debugger stack trace? or is that just a guess ecause the crash happened after a clear history?
(In reply to comment #15) Just a guess, sorry. It happened several times in different situations, but all with a delete history event in common. So I guessed that deleting history leads to crash. It might be another different issue.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
I'm going to resolve this, I think it was just a bad CC case, most likely the same as bug 426275, currently I don't see any crash reported for this signature.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Crash Signature: [@ nsNavHistoryResult::OnClearHistory() ]
You need to log in before you can comment on or make changes to this bug.