Feature Request: Fix places.sqlite 80MB Limit & Add True "Keep History Forever"

[jackie_4756]

To the Mozilla Development Team,

As someone who has been navigating the web since 1998 and comes from a hardware background, I am well aware of the argument that a massive browsing history database can theoretically slow down a system. However, the current way Firefox forcibly handles history retention is unacceptable for power users.

I have been using Firefox as my primary browser since October 2017. Everything worked perfectly until late December 2022, when Firefox suddenly began aggressively and automatically deleting my old history. I have tried every `about:config` modification available, and absolutely nothing stops this forced pruning.

The technical root cause is clear: the `places.sqlite` file appears to be tightly restricted, functioning with a hard cap around 80MB. Once the history data overflows this limit (much like an AI's context window overflowing), an aggressive auto-cleanup routine is triggered. Currently, my maximum retention is capped at about 6.5 years (my oldest surviving record is from March 22, 2019, which is nearing the chopping block). Even worse, simply attempting to interact with or view history older than 6 months triggers this deletion process almost 100% of the time.

**What Power Users Require:**
We need an absolute guarantee for our data. Specifically, a feature that allows users to command the browser to keep all history after a specific date (e.g., "August 20, 2019") **FOREVER**, under any circumstances. If Mozilla is worried about performance, simply display a warning prompt—but leave the final decision and consequence to the user.

Furthermore, this issue highlights two major gaps compared to other browsers:
**1. Lack of a "Keep History Forever" Option:** Browsers like Vivaldi natively offer a simple toggle to save history "Forever" without arbitrarily destroying data. There is no logical reason Firefox cannot offer the same basic right to data retention.
**2. Absence of Analytical Extensions:** The Chromium ecosystem benefits from powerful tools like "History Trends Unlimited." We strongly request Mozilla to officially support porting this extension to Firefox, or to build equivalent native data management and export tools.

Finally, let's put the "performance degradation" excuse to rest. In about a year, architectures like Intel's "Nova Lake" will hit the market with up to 52 cores. It is completely absurd to restrict user data control out of fear that a slightly larger SQLite database will drag down modern computing hardware.

Please give users back true ownership and control over their browsing history.

Thank you.

[Jon]

Thanks for submitting an idea to the Mozilla Connect community! Your idea is now open to votes (aka kudos) and comments.

[mrsimon0007]

The user argues that Firefox automatically deletes old browsing history due to limits on the places.sqlite database (around 80MB). They request a “Keep History Forever” option so power users can fully control data retention. They also suggest better history analytics tools or extension support, allowing users to manage, analyze, and export their browsing history without forced deletion.

[wybqogzigoxruxd]

I would like to support that idea. I want software to do only what I tell it to do. I don't want hidden automations that I am not aware of until it's too late.

Currently you can mitigate it with setting places.history.expiration.max_pages to some extent. However that too has exceptions - first of all it does not prevent downloads history to be deleted and second it does not prevent urls that are longer than 255 char from being deleted from your profile.

The main culprit is resource://gre/modules/PlacesExpiration.sys.mjs.

  // Some visits can be expired more often than others, cause they are less
  // useful to the user and can pollute awesomebar results:
  // 1. urls over 255 chars having only one visit
  // 2. downloads
  // 3. non-typed hidden single-visit urls
  // We never expire redirect targets, because they are currently necessary to
  // recognize redirect sources (see Bug 468710 for better options).
  QUERY_FIND_EXOTIC_VISITS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify (v_id, url, guid, visit_date, reason)
      WITH visits AS (
        SELECT v.id, url, guid, visit_type, visit_date, visit_count, hidden, typed
        FROM moz_historyvisits v
        JOIN moz_places h ON h.id = v.place_id
        WHERE visit_date < strftime('%s','now','localtime','start of day','-90 days','utc') * 1000000
        AND visit_type NOT IN (5,6)
      )
      SELECT id, url, guid, visit_date, "exotic"
      FROM visits
      WHERE (hidden = 1 AND typed = 0 AND visit_count <= 1) OR visit_type = 7
      UNION ALL
      SELECT id, url, guid, visit_date, "exotic"
      FROM visits
      WHERE visit_count = 1 AND LENGTH(url) > 255
      ORDER BY visit_date ASC
      LIMIT :limit_visits`,
    actions:
      ACTION.TIMED_OVERLIMIT |
      ACTION.IDLE_DIRTY |
      ACTION.IDLE_DAILY |
      ACTION.DEBUG,
  },

  // Finds visits to be expired when history is over the unique pages limit,
  // otherwise will return nothing.
  // This explicitly excludes any visits added in the last 7 days, to protect
  // users with thousands of bookmarks from constantly losing history.
  QUERY_FIND_VISITS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify
            (v_id, url, guid, visit_date, expected_results)
          SELECT v.id, h.url, h.guid, v.visit_date, :limit_visits
          FROM moz_historyvisits v
          JOIN moz_places h ON h.id = v.place_id
          WHERE (SELECT COUNT(*) FROM moz_places) > :max_uris
          AND visit_date < strftime('%s','now','localtime','start of day','-7 days','utc') * 1000000
          ORDER BY v.visit_date ASC
          LIMIT :limit_visits`,
    actions:
      ACTION.TIMED_OVERLIMIT |
      ACTION.IDLE_DIRTY |
      ACTION.IDLE_DAILY |
      ACTION.DEBUG,
  },

  // Removes the previously found visits.
  QUERY_EXPIRE_VISITS: {
    sql: `DELETE FROM moz_historyvisits WHERE id IN (
            SELECT v_id FROM expiration_notify WHERE v_id NOTNULL
          )`,
    actions:
      ACTION.TIMED_OVERLIMIT |
      ACTION.IDLE_DIRTY |
      ACTION.IDLE_DAILY |
      ACTION.DEBUG,
  },

While QUERY_FIND_VISITS_TO_EXPIRE does respect your places.history.expiration.max_pages setting with (SELECT COUNT(*) FROM moz_places) > :max_uris part, the QUERY_FIND_EXOTIC_VISITS_TO_EXPIRE above will still flag urls whose length is greater than 255 for removal regardless of places.history.expiration.max_pages.

I would like to see some setting that would turn off history expiration.