Firefox поставляется с новым значением по умолчанию "истекает история после..."?

Как установить, сколько месяцев запоминает история Firefox?

places.history.expiration.max_pages максимальное количество страниц, которые сохраняются до истечения срока действия страниц.

Тогда я несколько раз заполнял системный диск, и, возможно, FF автоматически настраивал параметры истории ("меньше истории"), когда это происходило - возможно ли это?

Может быть.

Новый компонент способен определять ваши аппаратные характеристики, особенно объем памяти, и адаптировать к нему срок годности.

Временное решение

Попробуйте использовать расширение Expire history по дням.

По иронии судьбы это расширение было написано разработчиком, который изменил предыдущее поведение. Смотрите сообщение в блоге ниже.

Как установить, сколько месяцев запоминает история Firefox?

Текущие версии Firefox сохраняют максимальное количество посещаемых страниц и не имеют ограничения по времени для истории. Firefox автоматически определяет, сколько страниц можно сохранить, не влияя на производительность.

Вы можете увидеть текущее значение этого максимума в качестве значения только для чтения places.history.expiration.transient_current_max_pages на about:config стр.

Посмотрите блог Марко Бонардо на эту тему:

http://blog.bonardo.net/2010/01/20/places-got-async-expiration

Источник Как установить, сколько месяцев истории запоминает Firefox?

Места получили Async Expiration

Ссылка на блог больше не доступна, но с машины обратного хода:

Лучший компонент срока действия теперь является частью модуля Places

На прошлой неделе, в пятницу, я отправил последние части нового компонента "Истечение срока действия". Это был один из проектов Firefox, предназначенный для ветки 1.9.3, вы можете найти более подробную информацию о начале этого проекта на его вики-странице.

Немного предыстории:

Первоначально истечение срока действия управлялось самим компонентом History на трех основных этапах: после каждого посещения, во время простоя, при завершении работы. Это имело различные недостатки. Во-первых, навигация была затруднена, поэтому мы переместили после каждого посещения шаг после каждой синхронизации между таблицами памяти и диска. Мы также сократили время простоя и время остановки.

Результат был лучше, но у нас были другие проблемы: у нас не было достаточно страниц с истекшим сроком действия, связанных с количеством посещений, и теперь компонент синхронизации был наполнен несвязанными функциями (и медленнее). Мы также все еще делали кучу вещей при закрытии.

В баге 516940 я очистил отключение, увеличив разделение между историей и истечением, и в этот момент было легче отделить его от истории в отдельном компоненте. Так что нового?

Новый компонент является компонентом JS, срок действия истекает поэтапно, каждые 3 минуты, с помощью простого адаптивного алгоритма, так что, если последний шаг не истек достаточно, следующий будет запущен позже, а если будет найдено больше элементов, чем истекшие, следующий шаг истекает больше! Это должно гарантировать, что мы не отстаем с истечением срока.

Он также использует async Storage API, это гарантирует, что мы будем выполнять ввод-вывод в отдельном потоке, поэтому мы не повредим вашей навигации.

Истечение времени простоя будет выполняться только на один больший шаг, затем оно остановится, пока вы не выйдете из простоя, таким образом, это не убьет ваш режим ожидания или батареи. Истечение срока действия при закрытии выполняется большим шагом, но не слишком большим, в большинстве случаев адаптивные шаги по истечении срока действия все равно должны гарантировать, что мы не истечем при завершении работы. Что изменилось для вас?

Новый компонент способен определять ваши аппаратные характеристики, особенно объем памяти, и адаптировать к нему срок действия, это означает, что вам больше не нужно настраивать количество дней истории или что-то еще. По этой причине мы удалили поле количества дней из панели настроек, и вам больше не нужно сообщать нам, сколько дней истории может обработать ваш компьютер.

Как насчет конфиденциальности? Что ж, мы, очевидно, обсуждали это и пришли к выводу, что поле дней не дает никакой реальной выгоды для конфиденциальности. Конечно, я мог бы установить это на 6 дней, но это не защитило бы меня с тех пор:

• Pref дней был "по крайней мере", так что для большинства пользователей это было подделкой
• Будучи асинхронным по истечении срока действия по определению, вы не можете быть уверены, что физически истек срок действия страниц
• даже если вы уменьшите историю до 6 дней, никто не может гарантировать, что у вас нет плохих записей в эти дни

Так как у нас есть лучшие инструменты для обеспечения конфиденциальности (и мы можем даже создавать новые, так что не стесняйтесь предлагать изменения и исправлять ошибки, связанные с файлами), такие как "Очистить недавнюю историю", "Частный просмотр" и "Забудьте" об этой странице / сайте, выбор был довольно ясным, мы хочу настоящую конфиденциальность, а не поддельную конфиденциальность.

Также исчезли скрытые настройки истечения срока действия, так что browser.history_expire_days, browser.history_expire_days_min, browser.history_expire_sites теперь заменены одним предпочтением place.history.enabled. Больше не нужно читать руководства по настройкам, чтобы браузер чувствовал себя быстрее.

Что вы можете настроить? В идеале вам не нужно ничего настраивать, и я советую вам не трогать преф. Кстати, ради информации у нас есть два новых скрытых предпочтения: place.history.expiration.interval_seconds - это количество секунд между каждым шагом срока действия, тогда как place.history.expiration.max_pages - максимальное количество страниц, которые мы сохраним до истечения срока действия. Мы прилагаем все усилия, чтобы иметь удовлетворяющие значения по умолчанию для всех, текущие значения построены, чтобы быть пессимистичными, мы оценим, как мы ведем себя с ними, и в конечном счете увеличим их в будущем, если мы чувствуем, что это необходимо.

Source https://web.archive.org/web/20151229082536/http://blog.bonardo.net/2010/01/20/places-got-async-expiration