Updates the default settings to delete history on shutdown. This matches
what's described in the comment directly above these settings and in the
librewolf documentation.
The change to not delete history by default was originally introduced in
48fa54f53a
with further changes in
as a response to librewolf/issues#2097
In that issue some users reported not being able to disable the cleanup
of history and as a fix for those users the default was changed to
disable the cleanup.
From what I can tell the original issue was caused by changes to the
preferences in the upstream, whereby the existing preferences were no
longer respected after the introduction of new preferences, thereby
causing the changes to seemingly revert for people who had configured
history to not be deleted. In any case these settings are respected
between restarts in the current version.
After that there were reports that these settings were not saved between
updates in the other direction:
I believe this is because the defaultPref changes to these settings
above flipped the settings for those users. This is because if a setting
is set to the current default, even if done so intentionally, it will
not be considered "modified" and so a change to the defaultPref will
override the intended setting. Specifically: Flipping a boolean
defaultPref will change that setting for everybody except those who have
it explicitly set using a pref override.
I can sympathize with people who had history they wanted to save
deleted, but I'm not sure that unexpectedly saving history for everybody
else is the right solution. Librewolf's documentation states that data
is deleted on close multiple times, and the comment immediately above
these settings says the same thing. I think it goes against the privacy
promises given to have the browser save data that people would
reasonably expect to have deleted. I don't think a browser that saves
all browsing history (and more) by default can reasonably call itself
focused on privacy.
Upstream firefox has a habit of refactoring preferences in a way that
changes the behavior for people who have non-default settings. .I've
experienced that very issue several times myself, for example I've had
to re-disable autoplay 3-4 times over the past 10 or years. I think
some way of writing preference translation tables that would set the
default value of new preferences based on the value of old preferences
would be an excellent feature to have introduced, but as far as I know
nothing like that is currently implemented.
Care is needed in reverting this change, as people who want history
saved may unexpectedly find it deleted yet again. This is ultimately a
limitation of the design of the preferences system, introducing a third
state to differentiate between unmodified and explicitly set to
default would be needed to overcome this issue. Absent that I think the
best solution would be to give users warning that this will be changed,
so that people who want to keep it set to false can do so with a pref
override.
Updates the default settings to delete history on shutdown. This matches
what's described in the comment directly above these settings and in the
librewolf documentation.
The change to not delete history by default was originally introduced in
https://codeberg.org/librewolf/settings/commit/48fa54f53a0a1483e15c8a14ba284bb92dbbeee1
with further changes in
* https://codeberg.org/librewolf/settings/commit/b85eaae0038eab71ddfa69f6d95e44d934ae2eff
* https://codeberg.org/librewolf/settings/commit/79c96b762a4834922df3943eb5dc45c2e8942055
as a response to https://codeberg.org/librewolf/issues/issues/2097
In that issue some users reported not being able to disable the cleanup
of history and as a fix for those users the default was changed to
disable the cleanup.
From what I can tell the original issue was caused by changes to the
preferences in the upstream, whereby the existing preferences were no
longer respected after the introduction of new preferences, thereby
causing the changes to seemingly revert for people who had configured
history to not be deleted. In any case these settings are respected
between restarts in the current version.
After that there were reports that these settings were not saved between
updates in the other direction:
* https://codeberg.org/librewolf/issues/issues/2711
* https://codeberg.org/librewolf/issues/issues/2588
I believe this is because the defaultPref changes to these settings
above flipped the settings for those users. This is because if a setting
is set to the current default, even if done so intentionally, it will
not be considered "modified" and so a change to the defaultPref will
override the intended setting. Specifically: Flipping a boolean
defaultPref will change that setting for everybody except those who have
it explicitly set using a `pref` override.
I can sympathize with people who had history they wanted to save
deleted, but I'm not sure that unexpectedly saving history for everybody
else is the right solution. Librewolf's documentation states that data
is deleted on close multiple times, and the comment immediately above
these settings says the same thing. I think it goes against the privacy
promises given to have the browser save data that people would
reasonably expect to have deleted. I don't think a browser that saves
all browsing history (and more) by default can reasonably call itself
focused on privacy.
Upstream firefox has a habit of refactoring preferences in a way that
changes the behavior for people who have non-default settings. .I've
experienced that very issue several times myself, for example I've had
to re-disable autoplay 3-4 times over the past 10 or years. I think
some way of writing preference translation tables that would set the
default value of new preferences based on the value of old preferences
would be an excellent feature to have introduced, but as far as I know
nothing like that is currently implemented.
Care is needed in reverting this change, as people who want history
saved may unexpectedly find it deleted yet again. This is ultimately a
limitation of the design of the preferences system, introducing a third
state to differentiate between _unmodified_ and _explicitly set to
default_ would be needed to overcome this issue. Absent that I think the
best solution would be to give users warning that this will be changed,
so that people who want to keep it set to false can do so with a `pref`
override.