Closed Bug 374529 Opened 14 years ago Closed 13 years ago

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

Categories

(Firefox :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 3 beta1

People

(Reporter: dietrich, Unassigned)

References

()

Details

(Whiteboard: PLCS-003d)

This is a tracking bug for item PLCS-003d in the Firefox 3 PRD.
Blocks: 374945
Flags: blocking-firefox3?
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.
Flags: blocking-firefox3? → blocking-firefox3+
Whiteboard: PLCS-003d
Target Milestone: --- → Firefox 3 alpha6
Is there more to this than just "support export to html format"?
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.
Assignee: nobody → sspitzer
Depends on: 384370
Retargeting to B1, not critical to A6.
Target Milestone: Firefox 3 alpha6 → Firefox 3 beta1
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)
Assignee: sspitzer → nobody
Target Milestone: Firefox 3 M7 → Firefox 3 M8
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.
> 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
Target Milestone: Firefox 3 M8 → Firefox 3 M9
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
No longer depends on: 384370
Need to add a litmus case since we now write out to bookmarks.html on exit instead of leaving it alone forever.
Flags: in-litmus?
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.
Status: RESOLVED → VERIFIED
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.
(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.
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.
Flags: in-litmus? → in-litmus+
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.