374529 - Make it easy for users to export their Places bookmarks for use in another application

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect)

Description

[Dietrich Ayala (:dietrich)]

This is a tracking bug for item PLCS-003d in the Firefox 3 PRD.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Uh, why did this get knocked down to a P2? Both mconnor and I think this needs to block, and are marking as such. We'll file a follow up PRD change request bug.

Comment 2

[(not reading, please use [e-mail] instead)]

Is there more to this than just "support export to html format"?

Comment 3

[Dietrich Ayala (:dietrich)]

finding owners for all the A6 blockers. can you please put a swag in the whiteboard? then we can review and load-balance at the next places meeting.

Comment 4

[Dietrich Ayala (:dietrich)]

Retargeting to B1, not critical to A6.

Comment 5

[(not reading, please use [e-mail] instead)]

sliding to m8.  and un-accepting as I'm not working on it.

I'm still not 100% sure what we want here.

dietrich / mconnor / basil, do you remember what this one entails?

Note, we have code now (thanks to christine) that can turn all of your bookmarks into json format without losing annotations, but we don't have code to read / write that to disk (like we do for import / export bookmarks.html)

Comment 6

[Dietrich Ayala (:dietrich)]

one way forward here might be to refactor the current import-export file i/o code to be format agnostic, and add a c++ json de/serializer.

however, the c++ import/export code is not pretty, and doing the above would be non-trivial. assuming the perf penalties aren't egregious, another approach might be to convert the whole shebang to js. we now have html and json serializers for query result nodes written in js, right? but this is also a huge project.

but really this prd requirement addresses export only. the quick way to do this might be to serialize and write the root out using the code seth mentioned, and add json as another available export format in the export wizard. this would provide a saner and more full-featured export format with less effort than rewriting all the existing import/export code. we could incrementally move other parts of import/export (like the backups) to use the json format.

Comment 7

[(not reading, please use [e-mail] instead)]

> we now have html and json serializers for query result nodes written in js, right?

Yes, see Christine's wrapNode() in utils.js

http://lxr.mozilla.org/seamonkey/source/browser/components/places/content/utils.js#457

Comment 8

[Dietrich Ayala (:dietrich)]

mconnor noted that this bug was originally the "continue exporting bookmarks.html" bug, and that bug 374528 is about adding user-friendly restore functionality to the organizer.

i'm going to:

- mark this as fixed
- free it of the dependency on bug 384370
- reopen bug 374528, make it dependent on bug 384370

QA: STV for this bug:

1. add a bookmark
2. close the app
3. verify that the new bookmark is in the bookmarks.html file in your profile

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Need to add a litmus case since we now write out to bookmarks.html on exit instead of leaving it alone forever.

Comment 10

[Tracy Walker [:tracy]]

verified with nightly build.

Al, this is referring to the manual method of export which is a little more discoverable in the Places Organizer > Import and Backup menu.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

When we close now, the bookmarks.html in the profile folder is update with changes made within places.sqlite (from what I saw when checking yesterday). This allows people to use the same profile with Firefox 2.0 and acts as an immediate backup. I assume that was the point.

We should have a litmus case to make sure that this backup as "bookmarks.html" in the profile folder is created and current with changes when the browser is exited.

Comment 12

[Dan Mills [:thunder]]

(In reply to comment #11)
> When we close now, the bookmarks.html in the profile folder is update with
> changes made within places.sqlite (from what I saw when checking yesterday).
> This allows people to use the same profile with Firefox 2.0 and acts as an
> immediate backup. I assume that was the point.

Note that there are some gotchas with this, see bug 381216 for a full report.

Comment 13

[Aakash Desai [:aakashd]]

As per Al's comments (In reply to comment #11), test cases for litmus were already created. They just had to be updated with the additional regression bug Id's on the 3.0 and 3.1 test runs. Here they are now:

For 3.0,
https://litmus.mozilla.org/show_test.cgi?id=5242

For 3.1, 
https://litmus.mozilla.org/show_test.cgi?id=6859



> When we close now, the bookmarks.html in the profile folder is update with
> changes made within places.sqlite (from what I saw when checking yesterday).
> This allows people to use the same profile with Firefox 2.0 and acts as an
> immediate backup. I assume that was the point.
> 
> We should have a litmus case to make sure that this backup as "bookmarks.html"
> in the profile folder is created and current with changes when the browser is
> exited.

Comment 14

[Gervase Markham [:gerv]]

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