Что именно обозначает число, указанное под “places.history.expiration.transient_current_max_pages” в Firefox?

Question 1

Пункт places.history.expiration.transient_current_max_pages на странице about:config в Firefox, предположительно, задает количество времени, в течение которого Firefox помнит страницы в своей истории.

Тем не менее, текущее значение по умолчанию, которое я вижу здесь, составляет 84175. Что это может означать??? Это не могут быть дни, потому что это будет составлять 230 лет!

Если это часы, то это всё равно 9,6 года, а если это минуты, то это 58 дней, и это кажется разумным, но всё равно это странный выбор для значения по умолчанию. Если это секунды, то это всего 23 часа, и я знаю, что это не может быть правильно.

Question 2

Официальная документация больше не доступна (также не удалось найти новое расположение).

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

NB: transient_current_max_pages больше не упоминается в исходном коде, но значение все равно вычисляется внутренне (даже если оно не предоставлено пользователю).

Раздел “Places Database” в about:support может быть использован для получения полезной информации. (NB: запуск этого кажется запускает очистку – сделайте резервную копию вашей базы данных сначала)

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

Определение places.history.max_pages и эффективный “геттер”.

Как используется это значение: https://searchfox.org/mozilla-central/source/toolkit/components/places/PlacesExpiration.sys.mjs#120

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

Мы видим, что “обычные” страницы удаляются только в том случае, если количество moz_places превышает places.history.expiration.max_pages. (ищите файл places.sqlite, если хотите проверить ваше текущее значение)

НО, видимо, также активен следующий запрос:

 // Некоторые визиты могут удаляться чаще других, так как они менее
  // полезны пользователю и могут засорять результаты awesomebar:
  // 1. URL длиной более 255 символов
  // 2. источники перенаправления и загрузки
  // Замечание: из-за опции REPLACE, это должно выполняться перед
  // QUERY_FIND_VISITS_TO_EXPIRE, у которого более полный результат.
  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 символов.

А также :

  // Находит сиротские URI в базе данных.
  // Заметьте, мы не будем уведомлять о единичных удаленных URI при History.clear(), так что мы не
  // запускаем этот запрос в таком случае, а просто удаляем URI.
  // Это может выполняться в середине добавления визита или закладки на новую страницу.
  // В таком случае, так как это асинхронно, может в итоге удалить сиротскую страницу
  // до того, как она получит новый визит или закладку.
  // Поэтому, так как новые страницы получают частоту -1, мы фильтруем по этому значению.
  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, казалось бы, сохранит большинство мест, но у меня есть ряд мест с “нулевой last_visit_date”, которые я определенно посещал.

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

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

В частности URL длиной более 255 символов и URL загрузок. (URL этой страницы содержит 119 символов)

Обновление:

Я подтвердил на основе предыдущей резервной копии places.sqlite, что моя установка Firefox (100k мест, max_pages установлено на 500k) удалила 325 мест за последние три месяца.

Большинство пропущенных записей являются мусором. например, “трекерные URL”, которые в итоге перенаправляются на более короткий URL, который сохраняется (facebook, google и др. являются основными “виновниками”).

Проблема не в том, что эти трекерные URL исчезли, а в том, что их визиты также исчезли, нарушая цепочку.

Пример:

URL, когда я кликнул на трекерный URL: google.com/search?q=give-me-news
Удаленный трекерный URL: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&so…...
Фактический URL: some-newspaper.com/articleX

Когда я нажимал на B, создавались два визита, A -> B и B -> C

Это позволяет мне позже узнать, что я прочитал статью X, потому что искал “give-me-news”

Firefox удаляет визит A -> B, потому что URL B — это мусор, и его неинтересно держать, и вдруг стало намного сложнее отследить источник. Все еще можно сделать хороший вывод, но это больше не простой SQL-запрос.

Если Firefox настаивает на удалении таких URL (что может быть правильным решением), было бы неплохо, если бы они могли либо оставить визит, либо изменить затронутые визиты. То есть изменить B -> C на A -> C, возможно, сохраняя запись о том, что ссылка в цепочке была удалена.

Последнее:

Почему они настаивают на удалении загрузок, я не понимаю — многие из моих загрузок имеют значимые имена файлов в URL и иногда было бы полезно получить их в качестве предложений в omnibar. (например, квартальные отчеты)

Создание резервной копии каждые 60 дней кажется достаточным для сохранения всей истории. sqlite, вероятно, не переиспользует старые идентификаторы, поэтому объединение резервных копий не должно быть слишком сложным.

Question 3

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

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

Question 4

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