Remove the ACTION.TIMED expiration

NEW
Unassigned

Status

()

enhancement
P2
normal
11 months ago
9 days ago

People

(Reporter: mak, Unassigned)

Tracking

(Depends on 2 bugs, {perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fxsearch])

Reporter

Description

11 months ago
We currently run 2 kind of expiration, one runs always and removes orphans, another one runs only when the database is over the given limit.

I'd like to remove the former and make the latter run less often (every 15 minutes or so).

To achieve this, we need to remove entries directly rather than relying on expiration doing it. History.jsm is already doing a good work at this, but keywords and bookmarks are not.
Since most of the APIs are async now, we can make them remove entries from moz_places and stop delaying that work.

At that point weekly maintenance will be the owner of orphans removal, while expiration should only take care of bringing the database back to a meaningful size.

This still requires some work, like removal of annotations and tags conversion, when we should check everywhere a place could be orphaned and remove the entry instead.

Particular care should also be taken for moz_inputhistory removal when we remove from moz_places.
Reporter

Updated

4 months ago
Duplicate of this bug: 1522611
Reporter

Comment 2

4 months ago

Adding some clarification, just in case. When a bookmark is removed currently we leave orphans behind and expect expiration to clean them up after a few minutes.
This has a few advantages from a perf point of view, but also leaves behind some privacy implications when expiration didn't run yet, and was mostly necessary when the bookmarks API was synchronous. Now the bookmarks API is async and can take care of its own orphans, so we can fix the orphans problem immediately.

Comment 3

4 months ago

I wanted to clarify one point from the last bug 1522611

I don't see the relation between removals and the about:config variable I suggested for backups, you're mixing up unrelated issues.
There won't be any changes to bookmark backups. We are happy with the status quo, we think it satisfies the needs for the majority of users. No doubt you can be unhappy about it, we can't satisfy everyone.

The relation was the series of events:

  1. The user desires to clean their profile of no longer wanted information, including bookmarks. They clear history and delete bookmarks in that order. The reason for not wanting to create a new profile is mainly convenience and wanting to keep your settings, themes, and plugins.

  2. After restarting Firefox, unwanted urls still pop up while typing, which is invasive and embarrassing. This is because of the default setting to "suggest" locations from places.sqlite. While you could simply turn the setting off, I wanted the information removed for good and was frustrated that it was not.

  3. In my personal case, I became alarmed and decided to delete places.sqlite since I was aware the file existed, thinking this would stop the urls from coming back. The automatic restoration feature then restored the unwanted urls as bookmarks, without asking for my consent, rather than me manually restoring via the "Import and Backup" bookmarks menu which takes two clicks and has a list of your available backups.

  4. You said "there is a simple option in about:config named browser.bookmarks.max_backups that you can set to 0, and the problem is solved" like it's some easy solution, but I said it's unreasonable to expect a user to fiddle with about:config or know about that particular setting when Step #1 above should work as intended, which would avoid this whole mess. So the comment was not "mixing up unrelated issues", but rather looking at the sequence as a whole.

I'm hoping this bug report will resolve this by fixing Step #1, since orphans will supposedly be removed immediately.

And I understand you won't be changing the automatic restoration behavior, I was just expressing my view. The developers or maintainers have proposed that I'm some sort of rare anomaly in the statistics, but I doubt that I'm the only one that has had problems with the address bar giving unwanted suggestions. Or tried to delete places.sqlite to get rid of data and be surprised when it comes back.

Now that I've thought about this again, I think another improvement would be a section under the "Address Bar" suggestions in "Privacy & Security", that gives the user an ability to disable automatic bookmark backups from the front-end. Right now it's a rather opaque feature that most people probably don't know is running in the background or making copies of their data, which inconveniences data sanitation if the user doesn't know about it. But I doubt you would allow that as it is potentially destructive. The user should have some way of being informed and made aware within the browser itself, however.

Further, I find it odd that somehow Firefox seems to be the only major browser that takes it upon itself to backup your bookmarks for you. For example Opera or Chrome, aside from any account sync behavior, don't bother assuming this is what you want and allow the user to take care of their own bookmarks. If you forget then that's on you, because it's the user's responsibility and not the browser's.

You need to log in before you can comment on or make changes to this bug.