307620 - Improve HTML bookmarks export for Firefox

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Bookmarks, enhancement)

Description

[Chris Lawson (gone)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050909 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050909 Camino/1.0+

When exporting bookmarks, Camino fails to export the last-visited date and
keyword. Firefox exports these, and Camino's failure to do so makes it difficult
for users of both browsers to keep bookmarks properly synchronised.

Reproducible: Always

Steps to Reproduce:
1. Export bookmarks from Camino
2. Import file into Firefox
3. Keywords and last-visited dates are lost

Actual Results:  
No keywords or last-visited dates get imported.

Expected Results:  
Properly export keyword and last-visited date for each bookmark, where applicable.

Comment 1

[Chris Lawson (gone)]

I've got a patch for this, but I'm holding off on it right now because we still
haven't quite figured out what exactly Firefox is exporting. Keywords was the
original request, but I'd like to see if we can export a matching bookmarks file.

Is there any particular reason we don't export a bookmarks file identical to
that produced by Firefox?

cl

Comment 2

[Chris Lawson (gone)]

Taking, fixed summary.

Comment 3

[Chris Lawson (gone)]

Un-taking and filing a new bug for the single component I've patched.

There are several pieces of metadata that Firefox exports that Camino doesn't
even know about:

ADD_DATE -- the date the bookmark was added
LAST_MODIFIED -- the date the bookmark was last edited (modified description,
keyword, URL, etc.)
ICON -- Firefox actually exports the site favicon as part of the bookmarks.html
file. I personally think this is unnecessary and just bloats the file.
LAST_CHARSET -- the character set used by the URL as of the last visit. Not sure
if this matters at all, but Firefox includes it.

The first two are pretty simple but will require modification of the Bookmark
class to support them. The latter two, well, I'm not sure we care about them
much anyway.

cl

Comment 4

[Chris Lawson (gone)]

Per Pink's comment 2 in bug 307743, when this is implemented, it should also be
smart enough *not* to stick blank attributes in the export.

cl

Comment 5

[Samuel Sidler (old account; do not CC)]

Do we really care about LAST_MODIFIED? I'm not sure it matters for anything. I
agree that ICON isn't needed at all.

The other two might be wanted, but can we match FF without any of them or must
we export certain things to allow importing correctly into FF?

Comment 6

[Chris Lawson (gone)]

Right now, the only real *problem* with our export is that it's discarding the
keywords (bug 307743). And that isn't causing any problems with Firefox; users
just don't want to lose data when they export (a reasonable expectation, I think).

The main reason I filed this bug is that I think we probably shouldn't be
causing *any* loss of data; i.e., if a Firefox user exports bookmarks, then
imports them into Camino, we should handle everything Firefox exports and be
able to export that back out. Right now, Camino is set up to handle most of the
critical stuff (again, no keywords, but I'm working on that), but there are just
a few little spit-and-polish type things that we don't handle at all yet.

My personal order of importance, of the things I mentioned in comment 3:

1) ADD_DATE
2) LAST_MODIFIED

ICON and LAST_CHARSET seem pretty irrelevant to me.

cl

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

> ICON and LAST_CHARSET seem pretty irrelevant to me.

I don't know what ICON is used for, but LAST_CHARSET is important for keyword
search URLs and has i18n consequences (at least in the rest of the Moz world;
the bug it seeks to fix somehow resolved itself WFM in Camino).  I don't
remember the bug where I read about this attribute, but I think it might be
referenced by jshin in that old Camino bug about wrong encodings with keyword
searches....

Comment 8

[Simon Fraser [no longer active]]

(In reply to comment #7)
> > ICON and LAST_CHARSET seem pretty irrelevant to me.
> 
> I don't know what ICON is used for, but LAST_CHARSET is important for keyword
> search URLs and has i18n consequences (at least in the rest of the Moz world;
> the bug it seeks to fix somehow resolved itself WFM in Camino).  I don't
> remember the bug where I read about this attribute, but I think it might be
> referenced by jshin in that old Camino bug about wrong encodings with keyword
> searches....

I think Camino should store last_charset too. It essentially remembers what
charset you were using when you last viewed the page specified by the bookmark,
so that pages with bad charset specification/detection load in your chosen
charset next time. This is probably useful for some CJK pages.

Comment 9

[Chris Lawson (gone)]

See comment 3; ICON is actually the raw favicon data. For some reason, Firefox
deemed it necessary to export the site favicon as part of its bookmarks file.
Why? Who knows. But I don't see much reason to export that at all.

Thanks for the info on LAST_CHARSET; we should probably be exporting that, too,
then. Make it three votes to keep that around. :)

cl

Comment 10

[Simon Fraser [no longer active]]

(In reply to comment #9)
> See comment 3; ICON is actually the raw favicon data. For some reason, Firefox
> deemed it necessary to export the site favicon as part of its bookmarks file.
> Why? Who knows. But I don't see much reason to export that at all.

Because they want to keep icons around independently of the disk cache (so that
you don't lose them, for example, when you crash).

Comment 11

[Chris Lawson (gone)]

(In reply to comment #10)
> (In reply to comment #9)
> > See comment 3; ICON is actually the raw favicon data. For some reason, Firefox
> > deemed it necessary to export the site favicon as part of its bookmarks file.
> > Why? Who knows. But I don't see much reason to export that at all.
> 
> Because they want to keep icons around independently of the disk cache (so that
> you don't lose them, for example, when you crash).

Now that your site icon cache is checked in, can we forget about exporting favicons in bookmarks?

cl

Comment 12

[Simon Fraser [no longer active]]

Yeah, don't bother with ICON data.

Comment 13

[Chris Lawson (gone)]

Taking to keep it on my radar.

Comment 14

[philippe (part-time)]

It would be noce if keywords (shorcuts) for tabgroups was also exported.
Firefox won't be able to use them, but it is handy if one uses the Export bookmark… as a way to create a backup.
For individual bookmarks, this was added in bug 307743.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #14)
> It would be noce if keywords (shorcuts) for tabgroups was also exported.
> Firefox won't be able to use them, but it is handy if one uses the Export
> bookmark… as a way to create a backup.
> For individual bookmarks, this was added in bug 307743.

This ought to be pretty easy to fix, I think.

|writeBookmarkFolder:toFileHandle:withIndentation:| currently does

324   if ([bookmarkFolder isToolbar])
325     attributes = @" PERSONAL_TOOLBAR_FOLDER=\"true\"";
326   else if ([bookmarkFolder isGroup])
327     attributes = @" FOLDER_GROUP=\"true\"";
328   [... write stuff]

And we should just need to do the equivalent of |writeBookmark:toFileHandle:withIndentation:|'s

375     if ([[bookmark shortcut] length] > 0)
376       [bookmarkLine appendFormat:@" SHORTCUTURL=\"%@\"", [bookmark shortcut]];

to append that to a folder's attributes before writing stuff.

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment 14/15 (as well as folder descriptions) are now bug 635061.