Import and export bookmark descriptions

VERIFIED FIXED in Firefox 3 alpha5

Status

()

P3
normal
VERIFIED FIXED
13 years ago
9 years ago

People

(Reporter: brettw, Assigned: mano)

Tracking

Trunk
Firefox 3 alpha5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

13 years ago
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.
(Reporter)

Updated

13 years ago
Summary: Importa and export bookmark descriptions → Import and export bookmark descriptions

Comment 1

13 years ago
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?

(Reporter)

Comment 2

13 years ago
(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.

Comment 3

13 years ago
"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.
(Reporter)

Updated

12 years ago
Priority: -- → P3
Target Milestone: --- → Firefox 3
(Reporter)

Updated

12 years ago
Assignee: brettw → nobody
Blocks: 375108
Assignee: nobody → dietrich
Created attachment 264220 [details] [diff] [review]
fix v1

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).
Attachment #264220 - Flags: review?(sspitzer)
Duplicate of this bug: 372161
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?
Attachment #264220 - Flags: review?(sspitzer) → review+
(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.
Whiteboard: [checkin needed]
Target Milestone: Firefox 3 → Firefox 3 alpha5
Whiteboard: [checkin needed]
Assignee: dietrich → mano
Created attachment 264506 [details] [diff] [review]
patch

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).
Attachment #264220 - Attachment is obsolete: true
Attachment #264506 - Flags: review?(sspitzer)
Comment on attachment 264506 [details] [diff] [review]
patch

r=sspitzer
Attachment #264506 - Flags: review?(sspitzer) → review+
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
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090128 Shiretoko/3.1b3pre
Status: RESOLVED → VERIFIED
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
You need to log in before you can comment on or make changes to this bug.