cookies.xul is unused and mostly unmaintained and should be removed.
Equivalent functionality in a well-maintained interface can be found
in the storage manager or the devtools storage inspector.
MozReview-Commit-ID: ILSt83hwN34
We recently updated the cookie settings in about:preferences to live outside
of the history mode settings, but did not change the way that changes to history
mode (toggling the privatebrowsing.autostart pref) reflected in the cookies section.
This patch takes care of that by moving the cookie related pieces out of the code
that sets history settings and makes sure that the respective functions get called
in all appropriate cases.
I also moved some site data settings code to be closer to the cookies code.
MozReview-Commit-ID: 6ly079uDz4C
After including cookies in the site data manager in bug 1421737, we would
like to move the cookies settings to the site data section to give them
more visibility and to unify site data and cookies.
Our UR has shown that our differentiation between site data and cookies
is not helpful to users and that they struggle with discovering the
cookie settings that are hidden in the "custom history" menu.
Since the cookie settings are quite powerful/potentially breaking,
we changed the top level preference from a checkbox to a radiogroup,
to be able to highlight the potential breakage associated with "deny".
This grouping is also recommended by the webstorage spec:
https://www.w3.org/TR/webstorage/#privacy
The cookies dialog is not removed yet, because it is still accessible from
Page Info, but bug 1348223 will likely remove it entirely.
MozReview-Commit-ID: Adisn70Ks2Q
This commit removes most of the cache section in about:preferences,
following the UX concept from bug 1421690. This is in the general
interest of de-cluttering privacy preferences and giving users controls
that are easier to understand and use.
The cache size is instead shown in the site data section and the cache
can be cleared using the "Clear Data" button in that same section.
MozReview-Commit-ID: 7PDTDgllFFI
Errors are collected via nsIConsoleService, shaped to a Sentry-compatible
format, and sent off. Reporting is on by default, and can be disabled using a
checkbox added to the privacy prefs in about:preferences.
Collected errors are sampled to avoid overloading the collection service; the
sample rate was determined by a previous Shield study that measured the number
of errors occurring in Nightly.
The feature is hard-disabled outside of Nightly and local builds, and the
preference is disabled by default in local builds. It is intended as a prototype
that will be evaluated and replaced by a more robust collection system if it
proves helpful.
Differential Revision: https://phabricator.services.mozilla.com/D561
MozReview-Commit-ID: 6aqUatXyuYs
Update the general page of about:preferences, as well as the Connection Settings panel, to show
when an extension is controlling proxy settings, and allow a user to disable the extension to
regain control.
MozReview-Commit-ID: HKYPkg78IOK
Update the general page of about:preferences, as well as the Connection Settings panel, to show
when an extension is controlling proxy settings, and allow a user to disable the extension to
regain control.
MozReview-Commit-ID: HKYPkg78IOK
Update the general page of about:preferences, as well as the Connection Settings panel, to show
when an extension is controlling proxy settings, and allow a user to disable the extension to
regain control.
This also updates some of the strings to use the phrase "is controlling" rather than "controls".
MozReview-Commit-ID: HKYPkg78IOK
This adjusts both the new Tracking Protection UI and the old Tracking Protection UI on
about:preferences to indicate when an extension is controlling Tracking Protection. It
will disable the controls on about:preferences if an extension is in control, and provide
a button to disable the extension.
MozReview-Commit-ID: G04jWrS6Pr9
This seemed to be working before by a fluke:
> Before bug 1375870, _constructAfterChildren was getting called several times,
resulting in change events triggering updatePrivacyMicroControls repeatedly.
> updatePrivacyMicroControls was using the auto-private-browsing checkbox to
decide whether to disable and hide the checkmarks of the other checkboxes.
> After bug 1375870, at the point when updatePrivacyMicroControls is called,
the preference value has not yet propagated to the auto-private-browsing
checkbox, so uPMC doesn't work correctly and is not called again.
Solution: use the actual preference value in uPMC.
MozReview-Commit-ID: 2AhRQwkjH5Q
This patch adds a |ForceUpdates| API in listmanager so when we change Safe Browsing tables,
we can use this API to force an update to ensure new tables are downloaded immediately.
If the update fails for any reason (Server is down for example), then the new tables will have
to wait until next update time.
MozReview-Commit-ID: 3Zh1pU8XaYo
This patch adds a |ForceUpdates| API in listmanager so when we change Safe Browsing tables,
we can use this API to force an update to ensure new tables are downloaded immediately.
If the update fails for any reason (Server is down for example), then the new tables will have
to wait until next update time.
MozReview-Commit-ID: 3Zh1pU8XaYo
The link to the phishin-malware support site was hard-coded in bug 1363051 and bug 1359289. The links have been built through the urlFormatter.
MozReview-Commit-ID: FmKGcEM4GZd
