404990 - Separator names/descriptions are lost when exporting as JSON

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, defect, P2)

Description

[Gonzalo HIGUERA DÍAZ]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b1) Gecko/2007110903 Firefox/3.0b1

When a bookmarks file saved from Firefox 2.x is imported into Firefox 3, all separators silently lose their descriptions.

I have reported the loss of separator names as bug 404983. I have given it minor importace because I am assuming that named separators are meant to be replaced by alternative bookmarks functionality such as the use of folders, tags, and better searching capabilites and that the behaviour is there to stay.

However, when importing bookmark files with an extensive use of named separators, the (silent) deletion of the information contained in the named separators is a major annoyance if Firefox 3 is meant to be encouraged as an upgrade to Firefox 2.

At a minimum, the user should be warned before the import or upgrade that such a loss is about to happen and let him decide on whether it is worth it.

It would be even better to provide a real upgrade path with minimal information loss. For example, named separators might be replaced (with a warning such as the former) by a combination of a folder with than name and an unnamed separator or something similar. Although this won't be to everybody's taste (given that the semantics of a named separator and the following elements vary case by case) at least information loss will be minimized which will help upgrading the layout to according to the new features and limitation(s).

Reproducible: Always

Steps to Reproduce:
1. Save Firefox 2 bookmarks in a file.
2. Import the file to Firefox 3.
Actual Results:  
The import is done silently and named separators irreversibly lose their description.

Expected Results:  
A warning should be shown about potential data loss and preferably a minimally lossy conversion should be offered or applied.

The problem might also show up when upgrading from Firefox 2 to Firefox 3, which would be worse than the importing scenario because:

  * the upgrade will probably be suggested to the user (either as an automatic update or through the media) and

  * the average user will not be aware of having any kind of backup of his original bookmarks layout (I aexpect it to be stored somewhere for a reasonable amount of time).

Comment 1

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

are the separator names really gone, or are they just not visible / editable in the firefox 3 UI?

looking at BookmarkContentSink::HandleSeparator() and nsPlacesImportExportService::WriteSeparator() we appear to be importing/exporting them, but I have not tested to confirm that this hasn't regressed.

(It did work at some point.)

Comment 2

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

a quick test shows that we are importing/exporting separator names.

I think this might be worksforme, at least for the name attribute case.

Comment 3

[(mostly gone) XtC4UaLL [:xtc4uall]]

i can confirm that the separator names are being shown after doing an import to Firefox 3 and an export back to Firefox 2.
though, the names are still not shown nor editable (see bug 381767) in the places UI ...

Comment 4

[Gonzalo HIGUERA DÍAZ]

(In reply to comment #3)
> i can confirm that the separator names are being shown after doing an import to
> Firefox 3 and an export back to Firefox 2.
> though, the names are still not shown nor editable (see bug 381767) in the
> places UI ...

I apologize for having assumed that if it wasn't in the UI it wasn't in the backend and not having tried importing back to test my assumption.

Comment 5

[Steve White]

I make heavy use of this feature and because of this bug have not been able to test/use Firefox 3 at all.  It may not be a heavily used feature, but WHY take out something once it has been released for a long time.  And it happens silently.  NOT GOOD.

Comment 6

[Thomas Wolff]

I am adding my comment here as well, in addition to <https://bugzilla.mozilla.org/show_bug.cgi?id=404983#c9> (see there for a rationale, please)
and <https://bugzilla.mozilla.org/show_bug.cgi?id=381767#c2>,
in order to point out that I really do NOT consider this a minor bug.
It's a serious impediment to everybody who has ever used the feature, 
because it's not just a feature, it's maintaining information (and making 
it accessible).

Comment 7

[Gonzalo HIGUERA DÍAZ]

(In reply to comment #4)
> (In reply to comment #3)
> > i can confirm that the separator names are being shown after doing an import to
> > Firefox 3 and an export back to Firefox 2.
> > though, the names are still not shown nor editable (see bug 381767) in the
> > places UI ...
> 
> I apologize for having assumed that if it wasn't in the UI it wasn't in the
> backend and not having tried importing back to test my assumption.

Today I take back those words of relief. While the separator titles may be imported and exported correctly from HTML into the SQLite back-end, backing up and restoring using JSON loses them[1]. Given that Weave uses Firefox 3's JSON parsing, those using this (_experimental_) extension might be bitten too. Perhaps others too.

However saddened I might be at this loss, at least I feel relieved not further care as a user on how this bug will develop. I am sure those who still cling to hope and haven't unknowingly lost their separator descriptions to the aforementioned issue would also prefer that a clear stance be taken on this issue rather than be left wondering.

[1] Tested on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1; checked with SQLiteManager.

Comment 8

[Marco Bonardo [:mak]]

needs discussions with ux team also, we're not going to change this for 3.1 at this stage. retargeting for 3.2.

Comment 9

[Dietrich Ayala (:dietrich)]

updating the summary to reflect that it's JSON-only.

Comment 10

[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

Comment 11

[Marco Bonardo [:mak]]

we are far from Firefox 2, we don't support names/descriptions from a long time, I don't think we are going to reintroduce them at this point.

Comment 12

[Thomas Wolff]

I can hardly believe someone is writing such a nonsense. First, this specific bug is about JSON which wasn't yet introduced in Firefox 2, so it's not about reintroducing a property that was overlooked with JSON.
Mainly, though, you are arguing that Mozilla has been neglecting this bug over years, ignoring lots of users (see related UI bugs, e.g. #404983) that raised good arguments for a valuable feature, and this should be an argument to finally - ehm - still ignore the request?
That's somehow like rejecting a long-year prisoner's request for pardon because he's been sitting so long already.

Comment 13

[Marco Bonardo [:mak]]

I'm sorry but whatever decision we take makes someone happy and someone not, there's hardly win-win situations in decision making.
The fact this bug hanged for so long means there's really no interest into it, and even if any resource would be available it would go into higher priorities that would help most users. Unless we decide to support names for separators there's no point in storing old Firefox 2 names in json (also cause after so many years of json without names they are very likely lost). If we'd ever decide to support names in separators, it will be normal to add them to json and html. So unless you have a very compelling argument by which they should be stored in json now, while we don't support nor allow to set them, bring it out.

Comment 14

[Thomas Wolff]

Your response is again absolutely not convincing, let me point out the reasons:
> I'm sorry but whatever decision we take makes someone happy and someone not, 
While this is true for many feature requests, certainly not for a feature that nobody is enforced to use, like this one - invalid argument.

> The fact this bug hanged for so long means there's really no interest into it, 
Nonsense! Many people have expressed their concern and annoyance in a number of related bug reports, over years. The fact that this has faded recently only shows that many have given up, not that they wouldn't have interest. Again you are using the fact that this bug has been ignored so long as a pseudo-argument for it further being ignored - this is logically invalid.
Please do not continue to rebuff us with invalid sophistications!

> and even if any resource would be available it would go into higher priorities that would help most users.
Understood in general, but:
1. It has been agreed already (in other related bug reports) that this would be easy to fix,
2. This is the way Microsoft has argued for its feature-driven development of buggy products, which is generally disapproved by technically interested people - should Mozilla really go the Microsoft strategy path? If so, it deserves to receive "Mozilla bashing" just like MS has always had to receive "MS bashing".

> Unless we decide to support names for separators there's no point in storing old Firefox 2 names in json
This bug, while started with reference to FF2, is really no longer about FF2 but about a missing feature.

> If we'd ever decide to support names in separators, it will be normal to add them to json and html. So unless you have a very compelling argument by which they should be stored in json now, while we don't support nor allow to set them, bring it out.
The fact that backup/restore of the names was discovered not to work has even been misused previously (in one of the related UI bug reports) as a feeble excuse not to consider the bug to be fixed. So it's kind of a blocking point. It's a circular argument that's being misused to discourage those asking for a valuable feature, by those who don't like to care about expert features for the sake of flattering the masses. Again bringing to mind the unfortunate allegory of "M bashing"...

It would really, finally, really be good if Mozilla would get a grip and turn towards a strategy of productive bookmarks handling (see #469426).

Comment 15

[Marco Bonardo [:mak]]

(In reply to Thomas Wolff from comment #14)
> This bug, while started with reference to FF2, is really no longer about FF2
> but about a missing feature.

you are making confusion with "supporting name on separators" bug, this specific bug makes no sense without that feature, nobody would ever care to store names in json if they are not even supported by the product.
Now, please accept we don't consider that feature a priority, if we'd ever see thousands of request for such feature in feedback reports, we'll reconsider that.