Closed Bug 494780 Opened 15 years ago Closed 15 years ago

Implement housekeeping to remove orphaned tags not associated with bookmarks.

Categories

(Firefox :: Bookmarks & History, enhancement)

x86
Windows XP
enhancement
Not set
normal

Tracking

()

VERIFIED DUPLICATE of bug 431558

People

(Reporter: geeknik, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090525 Shiretoko/3.5pre

Bug 444849 apparently fixed the problem that if you remove a bookmark, any tags that are associated with said bookmark are also removed, however, if you have any orphaned bookmarks from before this patch was implemented, they will not be removed. So I propose implementing some kind of housekeeping that will remove those orphaned tags not associated with bookmarks when a user updates their browser from one version to the next. It shouldn't take more then a couple of lines of code executing an sqlite query to do so. Someone in #places  gave me a snippet of code to do just that, but the pastebin no longer has a record of it, and I apologize for not remembering who gave it to me.

Reproducible: Always
already implemented in bug 431558
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
If this has been implemented on Shiretoko, it doesn't work, as I had to manually go into places.sqlite and remove tags by hand that I couldn't remove via the browser because they were causing the browser to hang.
that happens when you're on idle, could depend on your way to use the browser... on the other side if you don't have a copy of your old places.sqlite before the removals i can't argue if your case was different.
I have a copy of the old places.sqlite that had the orphan tag I couldn't remove except by going into places.sqlite outside of the browser. It's ~75MB.
if you can compress it, upload somewhere and share the link by mail would be great.
Otherwise i would only need a dump of moz_bookmarks table (always by mail is fine).
so, ennds up Brian issue was due to Stumble Upon, it added SU tag to about 7000 bookmarks, when he tried to remove that tag we did hang (we are still slow in removing bookmarks), so he thought the tag was empty and removed it manually.
Later preventive maintenance found those 7000 orphan bookmarks and moved them to unsorted bookmarks to prevent dataloss.
So the only issue i can see is that we are slow in removing bookmarks (bug 432706)
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.