This is the "Description" field in the 1.x bookmark properties dialog. It should be stored as an annotation on the URI. We'll need to do this if we do something interesting with descriptions.

Okay, so does the existence of this bug suggest the descriptions were lost when FF automatically imported it? :( (though I have a backup of the original bookmark fortunately) (In reply to Bug 318057 comment #11) > Does this export the description of an bookmark item? > > When I began to use a recent trunk build the browser automatically imported > bookmarks.html. (See bug 318817 comment 17, I migrated to Places after March 7) > Now I've exported bookmarks.html and it contains no descriptions. Does this > mean all description data are lost when imported, or the exporter doesn't > support it?

(In reply to comment #1) > Okay, so does the existence of this bug suggest the descriptions were lost when > FF automatically imported it? :( (though I have a backup of the original > bookmark fortunately) Yes. You are the first person I've ever heard of that has used the description, so this has not been a priority.

"description" is sometimes very handy : I use "Bookmarks Synchronizer" extension to create a xbel file of my public bookmarks that i display on my website, and so, the "description" is very useful. Even for my private bookmarks.

dietrch, see http://lxr.mozilla.org/seamonkey/source/toolkit/components/places/src/nsBookmarksHTML.cpp#1511 http://lxr.mozilla.org/seamonkey/source/xpfe/components/bookmarks/src/nsBookmarksService.cpp#5876

the testing part of this patch will of course have to be rectified with bug 376253 (many test changes there, and where the export testing is).

Comment on attachment 264220 [details] [diff] [review] fix v1 r=sspitzer, but a couple of questions: 1) + if (frame.mPreviousLink == nsnull) { + rv = mBookmarksService->GetFolderURI(frame.mContainerID, getter_AddRefs(placeURI)); + } + else if (frame.mPreviousId > 0) { + rv = mBookmarksService->GetItemURI(frame.mPreviousId, getter_AddRefs(placeURI)); + } why does not having a mPreviousLink (so we use mCountainerID) take precedence over having a mPreviousId when determining the place URI? 2) does this patch work for livemark descriptions?

(In reply to comment #7) > (From update of attachment 264220 [details] [diff] [review]) > r=sspitzer, but a couple of questions: > > 1) > > + if (frame.mPreviousLink == nsnull) { > + rv = mBookmarksService->GetFolderURI(frame.mContainerID, > getter_AddRefs(placeURI)); > + } > + else if (frame.mPreviousId > 0) { > + rv = mBookmarksService->GetItemURI(frame.mPreviousId, > getter_AddRefs(placeURI)); > + } > > why does not having a mPreviousLink (so we use mCountainerID) take precedence > over having a mPreviousId when determining the place URI? mPreviousId only gets cleared when a new link starts, whereas mPreviousLink gets cleared when a new container starts, so a null mPreviousLink is a reliable indicator that we're in a folder. some of the wonkiness in these tag handlers is to deal with unclosed tags. however, there's likely some clean-up that could be done in here.. resetting members on tag-close when possible, for example. > 2) > > does this patch work for livemark descriptions? no, this will need a follow-up.

Comment on attachment 264220 [details] [diff] [review] fix v1 needs to be updated per bug 379211

Updated to new APIs and includes support for livemarks,. I didn't update the tests to check the livemark description (will do so in the main import-tests bug).

Comment on attachment 264506 [details] [diff] [review] patch r=sspitzer

mozilla/browser/components/places/src/nsPlacesImportExportService.cpp 1.5 mozilla/browser/components/places/src/nsPlacesImportExportService.h 1.3 mozilla/browser/components/places/tests/unit/bookmarks.preplaces.html 1.2 mozilla/browser/components/places/tests/unit/test_bookmarks_html.js 1.3

verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090128 Shiretoko/3.1b3pre

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