Что именно представляет число, указанное в разделе "place.history.expiration.transient_current_max_pages" в Firefox?

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration

Указывает на фактический исходный код.

Интересные части находятся здесь: https://dxr.mozilla.org/mozilla-central/source/toolkit/components/places/nsPlacesExpiration.js#143

": max_uris" в запросах sql заменяется значением places.history.expiration.max_pages

Мы видим, что "обычные" страницы удаляются только если количество moz_places превышает places.history.expiration.max_pages, (найдите файл place.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-адрес, а запись о посещении URL-адреса), которые перенаправляют или принадлежат страницам с URL-адресами, превышающими 255 символов.

И это:

  // 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", которые я наверняка посетил.

В заключение:

Firefox удалит историю, даже когда places.history.expiration.max_pages не превышен...

В частности, URL-адреса длиннее 255 символов и ссылки для скачивания. (URL этой страницы длиной 119 символов)

Обновление: я подтвердил, основываясь на предыдущей резервной копии файла place.sqlite, что моя установка Firefox (100 тыс. Мест max_pages установлен на 500k) удалил 325 мест за последние три месяца.

Большинство пропущенных записей - мусор. например. "tracker urls" that end up redirecting to a shorter url that's kept (facebook, google, etc. are the primary "offenders")

The problem is not that these tracker urls are gone, but their visits is also gone, breaking the chain.

Пример:

A: Url when I clicked the tracker url: google.com/search?q=give-me-news

B: Removed tracker url: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so......

C: Actual url: some-newspaper.com/articleX

When I clicked on B two visits was created, A -> B and B -> C

That enables me to later find out that I read articleX because I searched for "give-me-news"

Firefox removes visit A -> B because the url of B is garbage and not interesting to keep around and suddenly it has become much harder to trace back to the source. Still possible to make a good guess but it's no longer a simple SQL query.

If firefox insists on removing such urls (which might very well be the correct thing to do, it would be nice if they could either leave the visit or modify the affect visits. Ie. modify B -> C to be A -> C, possibly keeping a record that a link in the chain has been removed.

Last: Why they insist on removing downloads I don't get - a lot of my downloads have meaningful filenames in the url and would sometimes be helpful to get as suggestions in the omnibar. (eg. quarterly reports)

Making a backup every 60 days seems to be sufficient to keep all history. sqlite doesn't reuse old ids (I think?) so merging the backups shouldn't be too hard.

Из документов: https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Places_Expiration

place.history.expiration.max_pages: максимальное количество страниц, которые могут быть сохранены в базе данных до истечения срока их действия. Значение по умолчанию рассчитывается при запуске и помещается в предпочтение place.history.expiration.transient_current_max_pages. Эта временная версия предпочтения просто отражает текущее значение, используемое по истечении срока, установив, что это не будет иметь никакого эффекта.

Аааа, я нашел ответ. Число не представляет количество времени, оно представляет максимальное количество страниц, которые Firefox хранит в своей истории. В этом есть смысл.