Closed Bug 454457 Opened 17 years ago Closed 15 years ago

Adding or editing bookmarks in the sidebar or the Library causes Firefox to crash every time [@ nsNavHistoryResult::OnItemMoved]

Categories

(Firefox :: Bookmarks & History, defect)

Product:
Firefox
Component:
Bookmarks & History
Version:
3.0 Branch
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: typo, Unassigned)

References

Details

(Keywords: crash)

Crash Data

User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-GB; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1 Every time I try to create a new folder in the bookmarks sidebar it hangs for ages and then crashes when I try to move that folder. This happens in Bookmark Organiser too. Bookmarking is also extremely slow with a few seconds hang time and doesn't always drag from the URL bar to the sidebar first time. This is extremely frustrating as I'm a big bookmarker. Reproducible: Always Steps to Reproduce: 1.Open bookmark sidebar 2.Create a new folder (hang) 3.Try to move this folder (crash) Actual Results: Crashes Expected Results: Normaly bookmarking action as performed in Firefox 2
The next time you crash, please do the following after you restart Firefox: Enter about:crashes in the location bar, find your crash in the list (by the time it happened), and report the bug id here.
Have you tried FF 3.0.2 with this "bug".
@Woody: I wasn't aware that FF 3.0.2 was available yet. I've not been promoted for any updates and the current version available for download is 3.0.1 on the Firefox download site. If you have a link and it's a stable version I'll give it a go. Has anyone else reported this problem?
@Steve Michaud: I've just tried creating a new folder in the bookmarks sidebar and then dragged it a couple of places up the directory tree and sure enough Firefox crashed again. I did what you said and entered in about:crashes in the location bar but the it didn't display the recent crash. It just happened today on 15/09/2008 but the last crash listed was 09/09/2008 - The last time I tried to bookmark :P Any ideas on the problem or a fix yet?
It seems like it only lists the crashes that I've reported via the pop-up that appears immediately after the crash. After creating another folder and trying to move it FF crashed again (at least its consistent) so I reported it and then entered about:crashes and it was listed. Here's the bug ID: 8d261e19-8325-11dd-a762-0013211cbf8a Hope this helps but keep me informed of the progress. This really is making FF unusable as my default browser.
typo that was a specialty with QA Companion, FF 3.0.2, It was a pre build.
It is what I am on now.
@woody: Sorry mate, I didn't make much sense of what you just said. :) Not sure what QA Companion is. If FF 3.0.2 is a pre build then I'd prob not rather use it yet as I use Firefox as my default browser and for development. I need it to be as stable as possible. If there's something that might fix the bookmarking issue then I'll give it a go though.
(In reply to comment #5) > 8d261e19-8325-11dd-a762-0013211cbf8a I've now failed several times (yesterday and today) to find a bug report (and crash stack) corresponding to this id. We've had several different kinds of problems with the crash-stats servers recently, and that's the most likely explanation. But if you don't mind, typo, please check that this number is correct (and complete). Or you could try crashing again and posting another one. > It seems like it [about:crashes] only lists the crashes that I've > reported via the pop-up that appears immediately after the crash. Correct.
I did notice then when I went to click on the link for the bug ID in about:crashes that it hung on the processing page for a long time. I left it an hour while it said "please wait - we are processing your report". Eventually it timed out (as it still seems to be doing now as I've just tried it again after creating another crash). I've double checked the bug ID from yesterday and I can confirm it is: 8d261e19-8325-11dd-a762-0013211cbf8a 15/9/08 13:55 For good measure I created another crash by using the method noted here and the bug ID is: 71245aa1-8400-11dd-9749-001cc45a2ce4 16/9/08 16:02 I've tried submitting this latest one by clicking the link in about:crashes but the problem of hanging on the processing page remains the same also. Hope this helps. If there's any more information I can provide please let me know. Cheers
I can now find crash logs for both your crash ids (from comment #10). The problems finding them seem to have been caused by a temporary server glitch (see bug 455418 comment #5). But, unfortunately, they're not much help. I should mention that I've tried and failed to reproduce your crashes. This is either because your report isn't detailed enough, or (more likely) because there's something different about your Firefox configuration. I notice that you're running some extensions (e.g. ColorZilla) and that you've installed at least one "input method" (SIMBL). So it'd be worthwhile temporarily disabling these, to see if it makes your problem go away. Temporarily disabling extensions is quite easy -- just run Firefox in "safe mode" (hold down the option key while starting Firefox). Disabling "input methods" is slightly more complicated: 1) Quit Firefox (if it's running). 2) Drag everything out of your /Library/Input Methods/ folder onto your desktop (but don't delete them). (Later you can restore these input methods by dragging them back.) 3) Run Firefox.
Signature nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) UUID 8d261e19-8325-11dd-a762-0013211cbf8a Time 2008-09-15 05:54:49-07 Uptime 247 Product Firefox Version 3.0.1 Build ID 2008070206 OS Mac OS X OS Version 10.5.4 9E17 CPU x86 CPU Info GenuineIntel family 6 model 15 stepping 6 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x13d285c Comments Crashing Thread Frame Module Signature Source 0 XUL nsNavHistoryResult::OnItemMoved mozilla/toolkit/components/places/src/nsNavHistoryResult.cpp:4244 1 XUL nsNavBookmarks::MoveItem mozilla/toolkit/components/places/src/nsNavBookmarks.cpp:1707 2 XUL NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 3 XUL XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 4 XUL XPC_WN_CallMethod mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 5 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1297 6 libmozjs.dylib js_Interpret mozilla/js/src/jsinterp.c:4852 7 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1313 8 XUL nsXPCWrappedJSClass::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523 9 XUL nsXPCWrappedJS::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559 10 XUL PrepareAndDispatch mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 11 XUL nsXPTCStubBase::Stub3 mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:1 12 XUL NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 13 XUL XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 14 XUL XPC_WN_CallMethod mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 15 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1297 16 libmozjs.dylib js_Interpret mozilla/js/src/jsinterp.c:4852 17 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1313 18 XUL nsXPCWrappedJSClass::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523 19 XUL nsXPCWrappedJS::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559 20 XUL PrepareAndDispatch mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 21 XUL nsXPTCStubBase::Stub3 mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:1 22 XUL nsTransactionManager::BeginTransaction mozilla/editor/txmgr/src/nsTransactionManager.cpp:1071 23 XUL nsTransactionManager::DoTransaction mozilla/editor/txmgr/src/nsTransactionManager.cpp:132 24 XUL NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 25 XUL XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 26 XUL XPC_WN_CallMethod mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 27 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1297 28 libmozjs.dylib js_Interpret mozilla/js/src/jsinterp.c:4852 29 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1313 30 XUL nsXPCWrappedJSClass::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523 31 XUL nsXPCWrappedJS::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559 32 XUL PrepareAndDispatch mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 33 XUL nsXPTCStubBase::Stub3 mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:1 34 XUL NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 35 XUL XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 36 XUL XPC_WN_CallMethod mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 37 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1297 38 libmozjs.dylib js_Interpret mozilla/js/src/jsinterp.c:4852 39 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1313 40 XUL nsXPCWrappedJSClass::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1523 41 XUL nsXPCWrappedJS::CallMethod mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:559 42 XUL PrepareAndDispatch mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:93 43 XUL nsXPTCStubBase::Stub15 mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_unixish_x86.cpp:13 44 XUL nsTreeBodyFrame::HandleEvent mozilla/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp:2701 45 XUL nsPresShellEventCB::HandleEvent mozilla/gfx/cairo/libpixman/src/pixman-access-accessors.c:1245 46 XUL nsEventTargetChainItem::HandleEventTargetChain mozilla/content/events/src/nsEventDispatcher.cpp:313 47 XUL nsEventDispatcher::Dispatch mozilla/content/events/src/nsEventDispatcher.cpp:483 48 XUL PresShell::HandleEventInternal mozilla/layout/base/nsPresShell.cpp:5921 49 XUL PresShell::HandlePositionedEvent mozilla/layout/base/nsPresShell.cpp:5809 50 XUL PresShell::HandleEvent mozilla/layout/base/nsPresShell.cpp:5662 51 XUL nsViewManager::HandleEvent mozilla/view/src/nsViewManager.cpp:1382 52 XUL nsViewManager::DispatchEvent mozilla/view/src/nsViewManager.cpp:1337 53 XUL HandleEvent mozilla/view/src/nsView.cpp:168 54 XUL nsChildView::DispatchEvent mozilla/widget/src/cocoa/nsChildView.mm:1713 55 XUL nsChildView::DispatchWindowEvent mozilla/widget/src/cocoa/nsChildView.mm:1726 56 XUL -[ChildView doDragAction:sender:] mozilla/widget/src/cocoa/nsChildView.mm:5435 57 XUL -[ChildView performDragOperation:] mozilla/widget/src/cocoa/nsChildView.mm:5502 58 AppKit AppKit@0x313e78 59 HIServices DoDropMessage 60 HIServices SendDropMessage 61 HIServices DragInApplication 62 HIServices CoreDragStartDragging 63 AppKit AppKit@0x311cfc 64 AppKit AppKit@0x310c1d 65 AppKit AppKit@0x310667 66 XUL nsDragService::InvokeDragSession mozilla/widget/src/cocoa/nsDragService.mm:313 67 XUL NS_InvokeByIndex_P mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp:179 68 XUL XPCWrappedNative::CallMethod mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2393 69 XUL XPC_WN_CallMethod mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1473 70 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1297 71 libmozjs.dylib js_Interpret mozilla/js/src/jsinterp.c:4852 72 libmozjs.dylib js_Invoke mozilla/js/src/jsinvoke.c:1313 73 libmozjs.dylib js_InternalInvoke mozilla/js/src/jsinvoke.c:1369 74 libmozjs.dylib JS_CallFunctionValue mozilla/js/src/jslong.c:5054 75 XUL nsJSContext::CallEventHandler mozilla/dom/src/base/nsJSEnvironment.cpp:1962
Keywords: crash
Summary: Adding or editing bookmarks in the sidebar or the Organiser cause Firefox to crash virtually every time. → Adding or editing bookmarks in the sidebar or the Organiser cause Firefox to crash virtually every time. [@ nsNavHistoryResult::OnItemMoved]
@Steven Michaud: I followed your suggestions and tried Firefox in safe mode. After testing it a little it doesn't seem to crash when I create a new folder and try moving it now but it still seems to hang for a while. When I create the new folder FF will seem to freeze for a few seconds and then display the spinning beach ball of death for about another 5 - 10 seconds. I know this isn't a huge amount of time but it does get tedious when trying to quickly bookmark some links. Most of the time I dump interesting pages into the Unsorted Bookmarks drawer than at some point on the weekend quickly sort them into my bookmarks. Firefox 2 never had any problem and I hung on for a couple of months before upgrading to make sure any kinks were ironed out (and plugins updated to run on FF 3). Bookmarking is such an important requirement for me and to have it crash and/or hang each time I try to add/edit them really slows things up and adds to the frustration. I really need to sort something out pretty soon or I'll have to either figure out a way to downgrade to FF 2 or switch to another browser. Let me know what the situation is and if you are any closer to a fix. One of the plugins could very well have been causing the crash but the hang is still there without them so this seems to be more of a browser issue. Cheers
> I followed your suggestions and tried Firefox in safe mode. Safe mode doesn't disable "input methods". So you also need to try that, separately (as I described it at the end of comment #11).
I presume you mean "Input Managers" rather than "Input Methods"? Input Methods is empty but Input Managers contains the following: - Smart Crash Reports - SIMBL - 1PasswordIM I followed your instructions and removed these to the desktop and restarted firefox in Safe Mode. However I STILL get that long delay each time I create a new folder of about 5-10 seconds with the spinning beach ball not allowing me to do anything else. The only difference seems to be that with everything enabled I had less of a delay and I could drag the folder straight after creating it. It was then that the crash occurs. This method just means it seems to hang for longer and not allow me to drag for that 5-10 second period. Currently I'm running Firefox 3.0.1 on a bare minimum install in Safe Mode with all plugins disabled.
> I presume you mean "Input Managers" rather than "Input Methods"? Yes, "Input Managers" is right. Sorry for the confusion. So now I'm completely stumped. The only other thing I can think of to create a new account (in the Accounts pref panel) and test in that.
Do the crash reports not provide any clues? Also, would the size of my bookmarks file be anything to do with it? I do have a fair few but it only totals 3.4MB. I wouldn't have thought this would cause a problem(?).
> Do the crash reports not provide any clues? Not really. Not by themselves. > Also, would the size of my bookmarks file be anything to do with it? Possibly. This suggests another experiment: Try testing in a fresh profile (one with only the default bookmarks). The easiest way to create a fresh profile (one which is reversible) is as follows: 1) Quit Firefox. 2) Open Terminal and change to the Library/Application Support/ directory (under your home directory). 3) Rename the Firefox directory to something like Firefox.old. 4) Restart Firefox.
I was just notified that Firefox 3.0.3 was available for download so I downloaded it and upgraded. I tested out the bookmarking issue by creating a new folder and to my surprise there was no delay, no spinning icon, and I drag it around as I pleased instantly without any crashes! It's a miracle! :) What was the problem in the end? Many thanks for fixing it though, it was starting to drive me crazy with all the crashing. :)
We *didn't* fix this ... at least not deliberately. I wonder if the new behavior is due to some kind of change on your system. Please download a new copy of Firefox 3.0.1 and try testing with that.
Hmmm strange... The bookmarking problem was definitely still there earlier on in the day as I experienced 2 or 3 more crashes whilst creating some new folders and then a couple of hours later I upgraded to FF 3.0.3 and the problem disappeared, somewhat to my surprise too. As far as I know nothing has changed on my system in that time with the one exception of the YSlow Firefox Addon. I've tested with this enabled and disabled in Firefox 3.0.3 and no crashes or delays occur with bookmarking either way. I don't mind checking with Firefox 3.0.1 again but can I run the two version side-by-side? Also where do I download it from as there only seems to be the latest version of 3.0.3 in the downloads area: http://www.mozilla-europe.org/en/#languages
Unfortunately it seems I spoke too soon. Whilst there does seem to be a bit of an improvement to the upper directories (those at the top level of the Bookmarks Menu) when I nest 3 or 4 directories deep the same problem still exists and it's crashed a couple of times this morning with the same delays beforehand. What seems slightly strange is that if I create a new folder at the root and then quickly created 3 or 4 underneath I can still move them around fine without any delays or crashes (this wasn't the case before I upgraded so some improvement at least) but when I create a new folder in some of my existing folders a few levels deep the delay and crashing problem occurs. Could my bookmarks file be damaged somehow? Before upgrading to FF3 as my main browser I ran MultiFox (http://www.dangerouslyawesome.com/2008/02/22/more-than-one-firefox-beta-to-rule-them-all-a-dave-martorana-concoction/) to have FF3 installed to browser test development work whilst keeping FF2 as my main browser. When I decided that FF3 should be safe enough to upgrade to as my main browser I got rid of Multifox, copied over my profile and from FF2, deleted all versions of Firefox and then clean installed the latest version of Firefox - 3.0.2 at the time. I'm not sure if this would have had any effect but the profile is designed to be copied over for times like that. I did run into a slight problem initially with some of my bookmarks being lost which this article resolved for me (http://kb.mozillazine.org/Lost_bookmarks_after_Firefox_3_upgrade). Not sure if any of that has any direct affect but other than the problems stated everything else seems to be fine. I'm happy to try either a new profile or Firefox 3.0.1 if you can confirm that my settings, addons, bookmarks etc are safe. I can't afford to lose them all and I use FF as my development browser on a daily basis. Cheers
For a while (for as long as you didn't have problems with Firefox 3.0.3), I suspected that your (old) copy of Firefox 3.0.1 had somehow become corrupted. But now that you're having the same sort of problems with 3.0.3 as you had with 3.0.1, I'm back to suspecting that your profile has somehow become corrupted. You really need to try Firefox (3.0.3) with a fresh profile, and without (at least initially) trying to import your old settings. I suspect this will clear up your problems. If it does, you will then need to add all your old settings by hand to your new profile. Here's something that *might* work to avoid having to re-enter all your bookmarks by hand: 1) Restore your old profile (by reversing the steps in comment #18). 2) Run Firefox 2 and export all your bookmarks to HTML. 3) Rename your old profile back to Firefox.old (as per comment #18), run Firefox 3.0.3, and try importing the bookmarks you exported from Firefox 2.
Man still unconfirmed... I had a problems with firefox 3, 3.0.1, 3.0.2 and updated and no more problems.
I've been testing the problem out with new profiles and I think I've limited it down to a problem with my bookmarks file. With a new install of FF3.0.3 and a new profile things seem fine. I can create new folders and move them instantly without any crashes or delays. However when I try to import my bookmarks again the problem seems to come back. I can create new folders and this seems ok but as soon as I try nesting new folders in old ones, maybe a few levels deep, the delay is back for about 5-10 seconds followed by a crash if I try to move it. The problem is however, is that I really don't want to lose my bookmarks that I've built up over the past 2 or 3 years with them all organised exactly where I can find them. Although some of them may not be relevant as time goes by the majority of them are and I wouldn't like to lose them. Is there any way I can clean up a bookmarks file to fix the problem? One interesting thing I tried was using Bookit (http://www.everydaysoftware.net/bookit/) to copy my firefox bookmarks to Safari. Then on a clean FF install I used bookit again with the reverse action to import from Safari to FF. When I tested this out it still produced the delay when adding new folders but it didn't seem to crash. Is it possible that the number of bookmarks I have could be causing the delay? The backed up .json file is only 1.6MB and the bookmarks.html file is only 3.4MB. I would have thought FF could handle sizes far bigger than this even if I do have a few thousand pages bookmarked within the file?
(In reply to comment #25) > Is there any way I can clean up a bookmarks file to fix the problem? I don't know of any. If you know HTML code reasonably well, you might try looking at it in a text editor, and making experimental changes. Make sure (of course) to keep a backup copy. > Is it possible that the number of bookmarks I have could be causing > the delay? I doubt it (though anything's possible). It's more likely (I think) to be a problem with how they're organized.
Have you updated to 3.0.3 if so you can wait for FF 3.0.4 coming soon.
There were reported 383 crashes with this stack trace against Firefox 3.0.3 on Linux. Not a top crasher yet. What surprises me we have a lot of comments on the crash reports. Would be great to have some STR for a fresh profile which raises this crash. List of reported crashes: http://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&query=nsNavHistoryResult%3A%3AOnItemMoved&date=&range_value=1&range_unit=months&do_query=1&signature=nsNavHistoryResult%3A%3AOnItemMoved(long%20long%2C%20long%20long%2C%20int%2C%20long%20long%2C%20int)
Status: UNCONFIRMED → NEW
Component: Bookmarks & History → Places
Ever confirmed: true
QA Contact: bookmarks → places
Hardware: Macintosh → All
Version: unspecified → 3.0 Branch
OS: Mac OS X → All
I'm just wandering what the latest on the problem is? I've now tried everything I can think of to solve the problem with the bookmarks file with imports/exports etc. I tried to run the html document though the W3C validator but it **** out every time (probably too big at 11500) lines. I'm fluent in HTML but checking a document that size line by line for a possible corruptions somewhere just isn't possible. I've tested it with new profiles and it seems to run fine (with or without addons installed) but I've not been able to see how it performs over time with more and more bookmarks added and edited. With the crash reports you've had with this issue on Linux is this likely to be more of a problem with Firefox 3 itself or with my particular profile/bookmarks file? I just need to know if I'm going to have to ditch all my bookmarks to fix the problem or if there's likely to be a fix coming along soon which will solve it? I'd be pretty peeved if I ditched all my bookmarks and then found out next week that you'd come up with a fix or that FF forms the same problem further down the line with my new bookmarks file. Cheers
(In reply to comment #30) This site (bugzilla.mozilla.org) is more-or-less "what you see is what you get". If someone is working on a bug, and close to a solution, you can usually tell from the comments. Also look to see if someone has "assigned" the bug to themselves. In this case, I can say with some confidence that there isn't (yet) enough information to work with (nobody can fix this bug with the information that's currently available). As I've said before, my best guess (at this point) is that there's something wrong with one or more of your bookmarks. Or conceivably you just have too many of them (although I think that's unlikely). If I'm right about that, this bug can't move forward until someone (you or someone else) provides specific examples of bookmarks that cause/trigger the behavior you've observed.
Typo, please make a full backup of your bookmarks or probably the whole profile. After that start to delete bookmarks step by step until the crash goes away. Probably there is something broken. You should try to isolate this bogus bookmark entry or entries. It would be great to get some information from you because as Steven already said, we don't have a clue yet why that happens. You can help us to solve this problem. Thanks!
Man you guys are slow to figure this out... I mean there's now 33 comments and still no solution... figures... HA... HAHA!!!
That's ok, I thought I'd just check to see what the situation was before I started taking drastic action. :) Henrik, I'll try your suggestion but I may have to wait until the weekend and spend a day dismantling all my bookmarks bit by bit. I'll start with the javascript bookmarklets and work down. I can imagine it would be pretty hard to pinpoint any exact bookmarks among thousands but I'll see how what it churns up. Hopefully I can be of some help and provide you with some information to help squash this bug. Cheers
Just be violent and remove whole folders e.g. Bookmarks Menu or Bookmarks Toolbar. You will get rid of a lot of bookmarks. If it solves the issue you have to go back and reduce the amount of bookmarks to delete. Just use the undo feature of the Library to revert changes. That will be helpful. Thanks for your willing to help us with this bug!
I've spent a bit of time this morning eliminating bookmarks and folders to try and narrow down the problem. From slowly elimanting folder by folder and then running the test of creating a few new folders nested within each other I noticed a consistent pattern. I didn't notice any particular bookmarks or folders that elimated the problem by themselves but I did notice that the more folders and bookmarks I elimated the slower the delay when creating a new folder and the less likely it was to crash when quickly creating the folders and moving them. I looked in the Bookmarks Library to see if I could find a utility which would give me the exact number of bookmarks to make note as I was going along but unfortunately I couldn't find one to provide an exact count. When I was down to the last 6 or 7 top-level folders the delay in creating a new folder was almost down to zero and no spinning timer. I could create nested folders, move them around like crazy and there were no crashes. This definitely limits the problem down to the bookmarks and not the addons, themes, or extras. I've tested it with a clean profile and with my exisiting profile of these modifications and the performance matches. Although this helps to narrow the problem down, it also poses a slight problem with the suggestion that if you build up more than 100-200 bookmarks (possibly in a nested folders) it will slow things up considerably and could eventually cause crashes. I'm sure there must be a high number of people out there with more bookmarks than that so I'm wandering if they suffer similar problems. If this is the case then this is a BIG problem for me. Let me know what you think. If you have any more specific questions then let me know and I can run a few more tests. Cheers
How's this situation coming along? Was the information I provided helpful? Do you need anything else to help fix the problem? It's still as prevalent as ever with 3.0.4 and 3.0.5 updates.
(In reply to comment #37) > Was the information I provided helpful? There's still not enough information here to work with. You still haven't provided enough information to allow us (and others) to consistently reproduce the problem. This would change if (for example) you could provide something like the following: A specific example of a bookmark that causes the browser to crash, together with detailed instructions on how to make that crash happen. A specific example of a bookmark that, if added a given number of times, causes the browser to crash (once again with detailed STR).
As I mentioned previously, there isn't a particular bookmark which causes the crash. From the process I followed it's almost definitely related to the number of bookmarks, i.e.; The more bookmarks I have saved the longer the delay, the longer the delay the more chance of Firefox crashing when either saving that bookmark or trying to move the folder within 5 or 10 seconds after the bookmark has been saved. These findings are consistent in all of my tests. When I strip the bookmarks down the delay decreases accordingly and the chances or a crash also decrease accordingly. My profile is 189.9MB on disk and my bookmarks (bookmarkbackups) total 8.9MB on disk. I have a fairly big profile and a fair collection of bookmarks but I'm sure there are plenty of others with similar sized files or number of bookmarks. Do others have the same problem with relational delay/probablility of crashing?
Typo, as already mentioned in comment 18 please create a fresh profile. After that close Firefox and copy the places.sqlite from the old profile into the new one and do the tests again. Are you able to crash Firefox again without modifying and installing anything else? If it also happens you should try to create a testcase. Means delete the places.sqlite file from the new profile and add as many bookmarks as you can. Just use some random URLs and probably c&p whole trees to other sub folders. When the crash starts to happen, you could attach the places.sqlite here or send it to me (if its too big to upload here). I can have test run to verify the crash. Thanks.
Summary: Adding or editing bookmarks in the sidebar or the Organiser cause Firefox to crash virtually every time. [@ nsNavHistoryResult::OnItemMoved] → Adding or editing bookmarks in the sidebar or the Library causes Firefox to crash every time [@ nsNavHistoryResult::OnItemMoved]
I'd like to point out, that finally steps to reproduce this bug exist. See attachment and comment #6 of Bug 476170.
(Make sure you visit Bug 476170 first, before you go to the sixth comment)
(In reply to comment #43) > (Make sure you visit Bug 476170 first, before you go to the sixth comment) A quick lesson in Bugzilla automagic linkification: bug 476170 comment 6 ;)
Thanks. Any news? Still crashes in Firefox 3.0.6. Steps to reproduce: bug 476170 comment 6
I can also reproduce crashes (on OS X 10.5.6) with the STR from bug 476170 comment #6. But only on the 1.9.0 branch (aka GranParadiso and FF 3.0.6) -- not on the 1.9.1 branch (Shiretoko) or mozilla-central (Minefield). I've attached a gdb trace to bug 476170 comment #8, plus another Breakpad crash id.
Still crashes in Firefox 3.0.7... Any news?
Since my bug 485772 was made a duplicate of this bug, I want to report my experience. I find that moving any folder or bookmark whether in the side bar or in the organizer will cause Firefox to crash about 20% of the time. I have a rather large set of book marks. I have not been able to find any pattern, it seems random. After you restart firefox you see that the move has been made. I don't mind any delay of creating a new folder.
The issue with this bug seems not to be that it hasn't got enough feedback, but rather not enought attention. -->You may simply vote for it. However I'm not sure whether non security bugs (even if reproducible crashers) that "only" appear in the 3.0.x series are to be fixed at all. Bug is still there with Firefox 3.0.8
Surely if it does appear in the 3.0.x range then it will always be there for future versions until it is fixed so wouldn't it be something that justifies a fix as it will affect everyone who likes to keep bookmarks? Having been so fed up with the constant crashing every time I saved a bookmark I dumped my bookmarks entirely, re-installed the latest version of Firefox, only installed the bare minimum of addons, and started with a clean bookmarks file. As soon as I created a folder in the sidebar view and then anoter one within that folder it crashed once again and the problem remains. Seriously, now it has been documented enough, is clearly reproducible, and must affect a considerably large number of people, how does it not justify a fix and why has no action been taken in over 7 months despite numerous new releases?
This bug has always been difficult to reproduce (which means there's a lot of information still missing from the various reports). And it may have disappeared on more recent "branches" -- the 1.9.1 branch (Firefox 3.1/3.5, Shiretoko) and the trunk/mozilla-central (Minefield). See comment #46. Please try to reproduce the STR from bug 476170 comment #6 with recent Shiretoko and Minefield nightlies (or with Firefox 3.1 beta 3).
Seems fixed for me with FF 3.1 beta 3. Even with my other unpublished tests. Because Firefox 3.5 release is delayed, the wish is of course to have it fixed in the *stable* series: Firefox 3.0.x
could have been fixed with bug 487040
For STR, first try bug 476170 comment #6?
looking at latest data things have dropped off quite a bit and the crash never seems to show in 3.5.x. Here is info on data collected for 08/17 9 total crashes for nsNavHistoryResult::OnItemMoved on 20090817 2 start up crashes inside 3 minutes 187.792 (days) total uptime for 9 of these crashes where user crashed within the last year 30046.7 (minutes) avg time since last crash os breakdown 5 nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) Mac OS X 10.5.7 9J61 1 nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) Mac OS X 10.5.8 9L30 1 nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) Mac OS X 10.5.7 9J3032 1 nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) Mac OS X 10.5.6 9G55 1 nsNavHistoryResult::OnItemMoved(long long, long long, int, long long, int) Mac OS X 10.4.11 8S165 distribution of versions where the crash was found on 20090817-crashdata.csv 6 Firefox 3.0.13 2 Firefox 3.0.11 1 Firefox 3.0.3 I'm going to mark this WORKSFORME as the result of not seeing this on 3.5.x any more. If that doesn't seem correct reopen.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
I have had no problems since 3.5. Good riddance to what was the worst annoyance to me for earlier versions of firefox. Thanks and kudos to all those that helped fix it.
This bug is particular for Firefox 3.0.x. Looking in the stats shows me 166 crashes in the last two weeks. Someone should decide if a fix is wanted on 1.9.0. WFM looks as the wrong solution for me -> Reopening. http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.0.13&query_search=signature&query_type=startswith&query=nsNavHistoryResult%3A%3AOnItemMoved&date=&range_value=2&range_unit=weeks&do_query=1&signature=nsNavHistoryResult%3A%3AOnItemMoved%28long%20long%2C%20long%20long%2C%20int%2C%20long%20long%2C%20int%29
Status: RESOLVED → REOPENED
status1.9.1: --- → ?
OS: All → Mac OS X
Resolution: WORKSFORME → ---
If it's 1.9.0-only, then 3.5.x is unaffected.
status1.9.1: ? → unaffected
i don't think we can take the fix on 1.9.0, the code is far, we would just risk to create new crashes due to some different code path. I'mo this is WFM for 3.5+, WONTFIX for 3.0, even if still present i don't see a large number of crashes on 3.0
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
does this still apply to any supported version of firefox? (e.g. 3.5 or higher?)
I'm resolving since I don't see reasons to not do so, the bug exists only on 3.0, while is fixed on 3.5+, 3.0 reached EOL. See comment 64 regarding reasoning for not backporting fixes to 3.0. as said, this is WONTIFX 3.0, WORKSFORME 3.5+, since bug is marked as 3.0 branch I'm going for the former.
Status: REOPENED → RESOLVED
Closed: 17 years ago → 15 years ago
Resolution: --- → WONTFIX
Crash Signature: [@ nsNavHistoryResult::OnItemMoved]
You need to log in before you can comment on or make changes to this bug.