Open
Bug 1356159
Opened 8 years ago
Updated 2 years ago
Stop storing a separate title field for all the bookmarks
Categories
(Toolkit :: Places, enhancement, P3)
Toolkit
Places
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox55 | --- | affected |
People
(Reporter: mak, Unassigned)
References
(Blocks 2 open bugs)
Details
We should probably stop storing a title field for the bookmarks, or better, we should store a title only for folders.
moz_places may grow a boolean field indicating if the title is user_set or not, and that would also allow to update bookmarks titles when a page is visited and the user didn't change the bookmark title (beware of > 3NN responses, we don't want to store "page not found" or "redirected" titles).
This would save some db space since in most cases users don't edit page titles when bookmarking (starring for example).
There's one downside though. some users like to set empty titles for some bookmarks on the toolbar, this wouldn't allow that.
Alternatively, we could maybe use the difference between NULL and empty string in moz_bookmarks, store NULL if the title is not edited, a string otherwise. This would still store double titles for edited bookmarks, so it would save a little bit less space, but would still be an improvement.
A question, if the history entrys is cleared or expired, the bookmarks are <No title>? Have to prevent the history entry being really full removed if it has bookmarks?
I hope this will have a revocation mechanism in the UI (Undo button) or Places (Last three days updated listed in Library? But it may bring new burdens. stored in session?) to retrieve the title before updating, which helps to recall memories.
Any possibility for a larger Places (limit) and improved algorithm performance to avoid do this? This inevitably loses some information and may bring some complaints.
Reporter | ||
Comment 2•7 years ago
|
||
This is unlikely to happen soon, in any case, expiring history wouldn't expire the title, it would work as it is now.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•