330025 - Bookmark folders with the same name merged after import

Status: VERIFIED FIXED

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

Description

[Adam Kowalczyk]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060309 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060309 Firefox/1.5

If there are two or more folders with the same name (in the same place in the hierarchy) they get merged when importing to a Places-enabled build. I.e. import results in only one folder containing the items from all the old folders.

Reproducible: Always

Steps to Reproduce:

Comment 1

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060309 Firefox/1.6a1
Yep, I see the same. 

Comment 2

[Brett Wilson]

This is the design. Why do you have two folders with the same name in the same parent?

We were going to be referencing folders with "path"-style names in several places, which is why it works this way. With the UI redesign, I'm not sure whether this will be necessary or not.

Comment 3

[Adam Kowalczyk]

(In reply to comment #2)
> This is the design. Why do you have two folders with the same name in the same
> parent?

I had some nameless folders on the Bookmarks Toolbar as quick "buckets". Anyway, I agree it's a minor issue.

> We were going to be referencing folders with "path"-style names in several
> places, which is why it works this way.

That's what I first thought. But I filed this bug, because you can create multiple folders with the same name in Places.

Comment 4

[Régis Caspar]

I see a similar issue but with bookmarks not folders and not after import. Everyday, I add Mozillazine's new "The Official Win32 xxxxxxxxxx [Trunk] build is not yet out" thread to my Places Bookmarks Toolbar. And after some amount of time this bookmarks is renamed automagically from "The Official Win32 xxxxxxxxx [Trunk] build is not yet out." to "xxxxxxxxx Trunk" which is the name of one item in Peter's "The official win32 builds" Feed (I livemarked it).
Note my RSS feeds belongs to a folder on my Places Bookmarks Toolbar.

Comment 5

[David A. Cobb]

IMNSHO, this could be a feature rather than a bug.
Without this behavior, importing from a backup (for example) results in duplicating a huge number of bookmarks.

Comment 6

[Nickolay_Ponomarev]

> I had some nameless folders on the Bookmarks Toolbar as quick "buckets".
> Anyway, I agree it's a minor issue.
> 
I used nameless folders in the same way. I can't agree that messing with user's data like that is a minor issue. If I had several folders, I expect to see them separate after upgrading.

The migration code could detect the folders with the same name and disambiguate them by adding [1], [2], etc to their names

> That's what I first thought. But I filed this bug, because you can create
> multiple folders with the same name in Places.

I just noticed that too, and I don't understand Brett's comment about this being "by design" anymore.

Comment 7

[Dietrich Ayala (:dietrich)]

I can no longer reproduce this bug. IIRC, when we stopped merging imported bookmarks (in favor of appending per Fx2 behaviour), this went away.

Comment 8

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

>when we stopped merging imported bookmarks (in favor of appending per Fx2 behaviour)

That was bug #381225: on import, places bookmarks builds attempt to merge in bookmarks.html, where firefox 2 appends bookmarks.

So marking this bug as fixed.  This is something we could add to the test suite(s).

Comment 9

[Tracy Walker [:tracy]]

verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007073005 Minefield/3.0a7pre.

litmus has a general import test case that we need to break out into a few more detailed cases.

Comment 10

[Sean Chitwood]

Testgroup: 3.0 Full Functional Tests (FFTs)
Subgroup: FX 3.0 FFT - Import
Testcase: Bookmark folders with the same name merged after import
Product: Firefox
Branch: Trunk
Author email: [e-mail]
Steps to perform:
1) Create a folder: Test-Import-Folder
2) Create Bookmark A (http://www.google.com) in Test-Import-Folder
3) Export bookmarks to Import-test1.html
4) Delete Bookmark A from Test-Import-Folder
5) Create Bookmark B in (http://www.yahoo.com) Test-Import-Folder
6) Export Bookmarks to Import-test2.html
7) Delete Bookmark B and Test-Import-Folder
8) Import Import-test1.html
9) Verify that Test-Import-Folder is created and contains Bookmark A
10) Import Import-test2.html
11) Verify that only one copy of Test-Import-Folder exists and it contains Bookmark A and Bookmark B

Expected Results:
Only one copy of Test-Import-Folder exists and it contains Bookmark A and Bookmark B. Bookmark A and B do not exist anywhere else

Regression Bug ID#: 330025

Comment 11

[Aakash Desai [:aakashd]]

Test case 7452 created to address regression issues for this bug in rel3.1.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #11)
> Test case 7452 created to address regression issues for this bug in rel3.1.

Which is not a valid test. Should we remove it from Litmus?

Comment 13

[Tracy Walker [:tracy]]

I corrected the test case to reflect identical folders *not* being merged after import.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

https://litmus.mozilla.org/show_test.cgi?id=7452

Comment 15

[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