User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032304 Minefield/3.0b5pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032304 Minefield/3.0b5pre When backing up with Json, it saves my bookmarks and smart bookmarks. However it fails to backup the title of the boomark. For example, bookmark this bug and it will come up with a title. However if you make a new profile, then restore your bookmarks it shows the title as "show cgi bug" this is the same for all bookmark titles. Json should retain these titles on restore/backup Reproducible: Always Steps to Reproduce: 1.Bookmark this page 2.Title appears in bookmark 3.Backup your bookmarks 4.Restore them in a new profile Actual Results: Bookmarks lose their titles in places smart bookmarks. Expected Results: Bookmarks should not lose their titles in places smart bookmarks.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032400 Minefield/3.0b5pre This WFM.

(In reply to comment #1) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032400 > Minefield/3.0b5pre > > This WFM. > Just made an attachment showing pics of the problem. Here is my build Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b5pre) Gecko/2008032405 Minefield/3.0b5pre

I can confirm that bookmarks itself work and see OK after backup/restore but seen via tags is not restored right! Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032405 Minefield/3.0b5pre (Firefox/3.0) ID:2008032405

I can't even reproduce it with the tags. The Bookmarks Toolbar folder with the Smart Bookmarks are not even overwritten by the backup.

I did try with a new profile... I do not know what is supposed to be restored to Smart Bookmarks but it looks like in those pictures...

(In reply to comment #6) > I can't even reproduce it with the tags. The Bookmarks Toolbar folder with the > Smart Bookmarks are not even overwritten by the backup. > Well I just tried a new profile, made a new smart bookmark tag, the chose backup and created another new profile. I restored the bookmarks, but still the title is missing and shows cgi bug thing, and of course all other tagged bookmarks have no title either. Antti, thanks for confirming in comment 5, you see the exact problem I am seeing. This is a definite bug thats needs fixing

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032503 Minefield/3.0b5pre WFM

Bug Confirmed On: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008032505 Minefield/3.0b5pre The bookmarks directly under the Smart Bookmarks folder successfully retained their titles, however the same bookmarks under the tag folders lost their titles when restored on a new profile just as your screen shot shows. However, I do not have the privileges to mark this bug as confirmed, so I guess we'll have to wait for someone with more power to come along and change the bug status. I tried it twice in a row with 2 different nightlys and it was reproduced both times.

Saw this and realised it happened before to me. I couldn't duplicate this to start off with. But then I tried restoring in to a NEW profile and was able to duplicate this again successfully. Confirming this and requesting it blocks, it's very annoying.

potentially this could be fixed by bug 419731, if that lands

(In reply to comment #12) > potentially this could be fixed by bug 419731, if that lands > Thanks guys, and Marco that bug was made by me. However when i asked them in that thread, they advised me it would not fix the json error so I made this bug. I guess we will not know if it fixes until that lands and being P2 it will make it for firefox 3. I have set a dependency on that bug.

(In reply to comment #13) > Thanks guys, and Marco that bug was made by me. However when i asked them in > that thread, they advised me it would not fix the json error so I made this > bug. oh well, sorry i had misunderstood the point :( still it's better having these separated since we should see where 419731 is going

(In reply to comment #6) > I can't even reproduce it with the tags. The Bookmarks Toolbar folder with the > Smart Bookmarks are not even overwritten by the backup. > Are you saying that the toolbar contents in the backup did not replace the existing toolbar contents? Can you file a bug if this is so?

Minusing for now as I can't see clear STR. Please feel free to renominate if I'm missing something, but this seems to be WFM?

Clear STR? Not sure what you mean by now, but it's absolutely not WFM, on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032705 Minefield/3.0pre ID:2008032705 Can still duplicate 100% 1. Make tags with memorable titles 2. Backup to JSON format 3. Make a new profile 4. Import JSON file 5. Go to Smart Bookmarks > Recently tagged

Sorry, but this also WFM with latest trunk build under Windows and OS X. I did exactly the same steps you mentioned. Could you attach your JSON file as a simple testcase? Thanks

Test case, 3 titles in the smart bookmarks > recent tags should be kept. (2 won't be kept because they were already broken in this test case). Remember to import in to a clean profile.

Damian, how old is your places.sqlite? Can you try with a fresh one? I can see that it's not working with your testcase but doing the backup from a fresh profile doesn't miss any tags under 'Recent Tags'. Dietrich, could it be probably caused by a broken/old places.sqlite?

I attached a second JSON file that does it 100% of the time for me. I reproduce by following these steps: 1. Start Minefield with it's profile directory EMPTY. That way it has to build a new profile from scratch. 2. Restore the JSON file from the Bookmarks Library (Organize Bookmarks...) 3. Now Under Smart Bookmarks->Recent Tags->*TAG_TITLE* the titles are gone. The titles were there when I made the backup file. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032805 Minefield/3.0pre

(In reply to comment #20) > Damian, how old is your places.sqlite? Can you try with a fresh one? I can see > that it's not working with your testcase but doing the backup from a fresh > profile doesn't miss any tags under 'Recent Tags'. > > Dietrich, could it be probably caused by a broken/old places.sqlite? > Well I keep importing it to a clean profile, so my places.sqlite is less than a day old. Maybe the bookmarks have been badly imported/exported at some point simmilar to bug 409945

(In reply to comment #22) > Well I keep importing it to a clean profile, so my places.sqlite is less than a > day old. Maybe the bookmarks have been badly imported/exported at some point > simmilar to bug 409945 Sorry when I was a bit unclear. I meant that you should backup the bookmarks from a clean profile. Just add a bookmark, tag it and run the backup. It shouldn't happen that way.

Henrik: renom if we can get STR that aren't WFM anymore - so far this bug looks UNCO to me.

Sorry I've not been back on to test this bug, not had access to my computer in a while. o.k, so I can still confirm this 100% of the time on a CLEAN profile using the latest nightly build, creating bookmarks on that clean profile and then restoring to that clean profile. Confirmed this on build: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9pre) Gecko/2008033105 Minefield/3.0pre ID:2008033105 Here are my steps to reproduce: 1. Make a clean profile 2. Go to: http://www.google.com/webhp?hl=en 3. Bookmark this, title it TEST1, tag it with Google 4. Check recently tagged from Smart Bookmarks, notice it's called Google and not TEST1 (not covered by the remit of this bug though) 5. Go to places library 6. Go to import and backup 7. Click backup 8. Save JSON file 9. Restart Firefox (making sure Google is NOT your homepage or Google is open in any tab before continuing) 10. Go to places library 11. Go to import and backup 12. Go to RESTORE 13. Go to choose a file 14. Select the file you saved 15. Go to Smart Bookmarks, choose recently tagged, go to the Google tag 16. Notice the found item, is neither titled Google or TEST1, but rather webhp I found a whole myriad of other bugs while testing this, but hopefully most of them should be fixed by bug 419731. Please confirm this asap and renom for blocking.

Right, I've tested this on multiple computers now, my steps for comment #25 work every time on a clean profile from the latest nightly build. I'm going to renom for blocking 1 more time as I posted those steps 2 days ago and we're not far away from code freeze, but no one has confirmed or denied if it works for them.

Damian, I am still getting the same issue here. Still holding out hope that bug 419731 fixes this, but Marc Bonardo is still waiting on a review from mano...

So the summary of this bug is misleading. Updating it accordingly. I can reproduce it with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040504 Minefield/3.0pre ID:2008040504

Dietrich, move this to back to a nom if you disagree, but it looks to me like this is a blocker that will be fixed by bug 419731, and is directly related to step 3 in comment 25 which implies tag containers are the cause.

(In reply to comment #25) > 4. Check recently tagged from Smart Bookmarks, notice it's called Google and > not TEST1 (not covered by the remit of this bug though) This is specifically fixed by bug 419731 > 5. Go to places library > 6. Go to import and backup > 7. Click backup > 8. Save JSON file > 9. Restart Firefox (making sure Google is NOT your homepage or Google is open > in any tab before continuing) > 10. Go to places library > 11. Go to import and backup > 12. Go to RESTORE > 13. Go to choose a file > 14. Select the file you saved > 15. Go to Smart Bookmarks, choose recently tagged, go to the Google tag > 16. Notice the found item, is neither titled Google or TEST1, but rather webhp At this point, can you confirm that the bookmark title is correct, in whatever folder you saved it? Also, do you have Firefox configured to clear history on shutdown? I was not able to reproduce step #16. In my test, it was entitled "Google", as it is in the browser history. Given the limitation of bug 419731, it could be named "webhp" *if* you import the backup into any profile where that URL is not currently in the browser history, for example: - you imported into a new profile - or you had cleared history before importing - or into a different profile in which the URL has never been visited This is because the proper page title ("Google"), is only set when you actually *browse* to the page. Another way to reproduce this could be to: 1. right-click the toolbar, select "New Bookmark..." 2. create the bookmark with "http://www.google.com/webhp?hl=en", entitled "Test 1" and tag it "google" 3. open the Recent Tags smart bookmark, open "google" tag The title of the tagged URL is "webhp". > I found a whole myriad of other bugs while testing this, but hopefully most of > them should be fixed by bug 419731. Have you filed bugs for these?

My understanding is that JSON replaces everything, if you've followed steps 9 - 14 correctly, Google should not be in the browser history. The orriginal bug did not have the URLs in the history, nor would it be expected to have hte URLs in the history, that's kind of the point I thought. > Have you filed bugs for these? No, I didn't have time when I was testing and I've forgotten them now. I'll do some more testing when bug 419731 lands, but it seems pointless till then.

(In reply to comment #31) > My understanding is that JSON replaces everything, if you've followed steps 9 - > 14 correctly, Google should not be in the browser history. JSON backup/restore only is for bookmarks, tags and annotations. It doesn't back up or restore history. It does not delete history in a profile into which a JSON backup is being imported. > > The orriginal bug did not have the URLs in the history, nor would it be > expected to have hte URLs in the history, that's kind of the point I thought. Ok, that's fine if the original bug did not have the bugs in history. In that case, bug 419731 will fix this by displaying the imported bookmark title in the tag container. It sounds like the steps you provided in comment 25 are invalid absent at least one of the 3 scenarios I gave in comment 30. In which case this bug is not valid. > > > Have you filed bugs for these? > > No, I didn't have time when I was testing and I've forgotten them now. I'll do > some more testing when bug 419731 lands, but it seems pointless till then. > If you don't have time to file them, feel free to let us know in #places or email me.

huh, I'm very confused about what you mean about the bug being possibly valid. Look at step 4 of comment #0, of course the URLs won't be in the history. I must have been in a rush when I wrote comment #25 or something, step 9 should be "close Firefox and load clean profile".

(In reply to comment #33) > huh, I'm very confused about what you mean about the bug being possibly valid. > > Look at step 4 of comment #0, of course the URLs won't be in the history. I > must have been in a rush when I wrote comment #25 or something, step 9 should > be "close Firefox and load clean profile". > Sorry, I was confused by the comment #25 steps. You are correct that this bug is valid: We do not currently backup and restore the actual page title of bookmarks. I'm morphing this bug to cover that portion of the original report. It is not a blocker though -> Renominating. The blocker issue is that under tag containers, history titles are used instead of bookmark titles, and that's being fixed in bug 419731. To resolve this bug, we could either: 1. backup and restore history titles along with each bookmark 2. whenever a bookmark is added, silently fetch the bookmarked URL so that it's history record is complete

Won't bug 419731 fix this anyway? Because tags are becoming query based, so the title from the bookmark should just be used.

from command #34 "To resolve this bug, we could either: 1. backup and restore history titles along with each bookmark 2. whenever a bookmark is added, silently fetch the bookmarked URL so that it's history record is complete I am not sure tieing 'history' to the bookmark is a good idea, as there have been several discussions floated around reference 'privacy' issues, mostly in the way the Awesome bar works. Many are not understanding when they clear their 'Private Data' that they still have items showing in the drop-list of the Awesome bar, thinking their private data has not been cleared, not realizing they are bookmarks and tags. Tieing 'History' to this would only complicate the issue I think. Some discussion/concerns here: http://forums.mozillazine.org/viewtopic.php?t=646675

bug 419731 covers the blocker issue, what's left seems either trivial or wontfix.

Hi, I am marking this bug as fixed, as the checkin of bug 419731 has now resolved the issue. Only thing now is favicons are not restored, is there a bug for that? ( i guess it would be classed as trivial )

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

(In reply to comment #38) > Hi, I am marking this bug as fixed, as the checkin of bug 419731 has now > resolved the issue. Only thing now is favicons are not restored, is there a bug > for that? ( i guess it would be classed as trivial ) We do not store favicon yet. See bug 423126.