“places.history.expiration.transient_current_max_pages”下列出的数字在Firefox中代表什么？

Question

Firefox about:config 页面中的条目“places.history.expiration.transient_current_max_pages”应该设置 Firefox 在其历史记录中记住页面的时间。但是，我在这里看到的当前默认数字是 84175。这到底代表什么？？？不可能是几天，那就是230年！如果是小时，那么它仍然是 9.6 年，如果是分钟，那么它是 58 天，这似乎是合理的，但对于默认长度来说仍然是一个奇怪的选择。如果是几秒钟，那只是 23 小时，我知道这不可能是对的。

Answer 1

官方文档不再可用（也找不到新位置）。

places.history.expiration.max_pages：开始过期之前数据库中可以保留的最大页数。默认值在启动时计算并放入places.history.expiration.transient_current_max_pages首选项中。这个暂时版本的首选项只是镜像到期时使用的当前值，设置它不会有任何效果。

transient_current_max_pages源码中不再提及。

about:support中的“地点数据库”部分可用于获取有用的信息。（注意：运行似乎是在运行清理 - 首先备份数据库）

指向实际的源代码。

有趣的部分在这里：https://searchfox.org/mozilla-central/source/toolkit/components/places/PlacesExpiration.sys.mjs#120

:max_urissql 查询中的值替换为places.history.expiration.max_pages

我们看到，只有当数量moz_places超过时，“常规”页面才会被删除places.history.expiration.max_pages。（如果您想检查当前值，请搜索places.sqlite 文件）

但这个查询似乎也很活跃：

 // 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
  // 2. redirect sources and downloads
  // Note: due to the REPLACE option, this should be executed before
  // QUERY_FIND_VISITS_TO_EXPIRE, that has a more complete result.
  QUERY_FIND_EXOTIC_VISITS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify (v_id, url, guid, visit_date, reason)
          SELECT v.id, h.url, h.guid, v.visit_date, "exotic"
          FROM moz_historyvisits v
          JOIN moz_places h ON h.id = v.place_id
          WHERE visit_date < strftime('%s','now','localtime','start of day','-60 days','utc') * 1000000
          AND ( LENGTH(h.url) > 255 OR v.visit_type = 7 )
          ORDER BY v.visit_date ASC
          LIMIT :limit_visits`,
    actions: ACTION.TIMED_OVERLIMIT | ACTION.IDLE_DIRTY | ACTION.IDLE_DAILY |
             ACTION.DEBUG,
  },

操作列表表明该操作每天运行。

它不依赖于expiration.max_pages，如果我正确阅读代码，它会删除重定向或属于 url 超过 255 个字符的页面的访问（不是实际的 url，而是如何访问 url 的记录）。

和这个：

  // Finds orphan URIs in the database.
  // Notice we won't notify single removed URIs on History.clear(), so we don't
  // run this query in such a case, but just delete URIs.
  // This could run in the middle of adding a visit or bookmark to a new page.
  // In such a case since it is async, could end up expiring the orphan page
  // before it actually gets the new visit or bookmark.
  // Thus, since new pages get frecency -1, we filter on that.
  QUERY_FIND_URIS_TO_EXPIRE: {
    sql: `INSERT INTO expiration_notify (p_id, url, guid, visit_date)
          SELECT h.id, h.url, h.guid, h.last_visit_date
          FROM moz_places h
          LEFT JOIN moz_historyvisits v ON h.id = v.place_id
          WHERE h.last_visit_date IS NULL
            AND h.foreign_count = 0
            AND v.id IS NULL
            AND frecency <> -1
          LIMIT :limit_uris`,
    actions: ACTION.TIMED | ACTION.TIMED_OVERLIMIT | ACTION.SHUTDOWN_DIRTY |
             ACTION.IDLE_DIRTY | ACTION.IDLE_DAILY | ACTION.DEBUG,
  },

表示专门属于此类访问的 url（又名“地点”）稍后将被清除..（不确定 h.foreign_count 是什么）

这h.last_visit_date IS NULL似乎可以保存大多数地方，但我有很多我肯定访问过的带有“null last_visit_date”的地方。

综上所述：

即使places.history.expiration.max_pages未超过，Firefox 也会删除历史记录...

特别是长度超过 255 个字符的 URL 和下载 URL。（此页面的 URL 长度为 119 个字符）

更新：

我已经根据以前的places.sqlite 备份验证了我的firefox 安装（100k 个位置，max_pages设置为500k）在过去三个月中删除了325 个位置。

大多数缺失的条目都是垃圾。例如。“跟踪网址”最终会重定向到保留的较短网址（Facebook、谷歌等是主要的“罪犯”）

问题不是这些跟踪器网址消失了，而是它们的访问也消失了，从而破坏了链条。

例子：

• 我点击跟踪器网址时的网址：google.com/search?q=give-me-news
• 已删除跟踪器网址：https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so .....。
• 实际网址：some-newspaper.com/articleX

当我点击 B 时，创建了两次访问，A -> B 和 B -> C

这使我后来发现我阅读了articleX，因为我搜索了“give-me-news”

Firefox 删除了访问 A -> B，因为 B 的 url 是垃圾，并且保留起来没有意义，突然之间，追踪源头变得更加困难。仍然可以做出很好的猜测，但它不再是一个简单的 SQL 查询。

如果 Firefox 坚持删除此类 URL（这很可能是正确的做法，如果他们可以离开访问或修改影响访问，那就太好了。即将 B -> C 修改为 A -> C，可能会保留链中某个链接已被删除的记录。

最后的：

为什么他们坚持删除我不明白的下载内容 - 我的很多下载内容在网址中都有有意义的文件名，有时在多功能栏中获取建议会很有帮助。（例如季度报告）

每 60 天进行一次备份似乎足以保留所有历史记录。sqlite 不会重用旧的 ID（我认为？），因此合并备份应该不会太难。

Answer 2

啊啊，我找到了答案。该数字并不代表时间量，它代表 Firefox 在其历史记录中保留的最大页面数。这就说得通了。