This also removes any redundant Ci.nsISupports elements in the interface
lists.
This was done using the following script:
acecb401b7/processors/chromeutils-generateQI.jsm
MozReview-Commit-ID: AIx10P8GpZY
--HG--
extra : rebase_source : a29c07530586dc18ba040f19215475ac20fcfb3b
***
Bug 1454202: Part 1a - Auto-replace uses of callback-based AddonManager APIs with Promise-based versions. r=aswan
This was done using the following script:
4cd5ae9597/processors/aom-api-generators.jsm
MozReview-Commit-ID: 8hobLz15a66
***
Bug 1454202: Part 1b - Manually fix eslint errors after auto-rewrite. r=aswan
This also deletes an obsolete test whose xpcshell variant was already deleted.
MozReview-Commit-ID: DM9W9Q2SVIE
***
Bug 1454202: Part 1c - Manually fix non-eslint issues after auto-rewrite. r=aswan
MozReview-Commit-ID: DtMscWZuExc
--HG--
extra : rebase_source : d4c2f80bdf02ec4a07e3713a9ae1823145d25942
The OfflineAppCacheHelper was apparently introduced after the Sanitizer had been
forked for Fennec and so far nobody bothered to use it there as well.
MozReview-Commit-ID: 42Uk5hfvf9y
--HG--
rename : browser/modules/offlineAppCache.jsm => toolkit/modules/offlineAppCache.jsm
extra : rebase_source : 77e542dbbdfea62b918b89b4c0799be7e3f89ef9
The OfflineAppCacheHelper was apparently introduced after the Sanitizer had been
forked for Fennec and so far nobody bothered to use it there as well.
MozReview-Commit-ID: 42Uk5hfvf9y
--HG--
rename : browser/modules/offlineAppCache.jsm => toolkit/modules/offlineAppCache.jsm
extra : rebase_source : b7010f732ca13583fd2b2c62102b4ea1c13a4cc6
Select next item in list when removing items in Site Data Manager. When there
are multiple selected sites, it will select the next item after the last
previously selected item.
Differential Revision: https://phabricator.services.mozilla.com/D965
Select next item in list when removing items in Site Data Manager. When there
are multiple selected sites, it will select the next item after the last
previously selected item.
Differential Revision: https://phabricator.services.mozilla.com/D965
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
--HG--
extra : rebase_source : 9aaec03b54128ef3ece1e96e46269457feb43546
This commit adds a helper module for doing common tasks
related to site data, such as adding dummy data and getting usage.
There are many places that would potentially need to be cleaned
up to use this module instead, but I consider that work (and the
likely try failure fallout) out of scope for this bug.
MozReview-Commit-ID: 5eMDgHhClsO
--HG--
extra : rebase_source : e515a1a12f6a665f6a4b96deec73790540755189
Also adds new crh locale and in-content prefs test fix.
MozReview-Commit-ID: DFs0s710wZ4
--HG--
extra : rebase_source : 7edf0d5401cdb8da9559d98fe7837d6f23889c85
The shims that this rule tests for no longer exist.
MozReview-Commit-ID: DMgP7Hczavc
--HG--
extra : rebase_source : 765ddd5c62c9449c07ed050e44d86a3bd5c0ae64
extra : amend_source : 627a7694ac07182200f876901ded7a34721cd228
Also adds new crh locale and in-content prefs test fix.
MozReview-Commit-ID: DFs0s710wZ4
--HG--
extra : rebase_source : fc74ec586b85c3b8a34d61027b98c0a2ff7a1291
Reorder the construction of Preference objects so network.proxy.autoconfig_url gets constructed before network.proxy.type, which will ensure that networkProxyAutoconfigURL is set to the value of network.proxy.autoconfig_url before network.proxy.type construction triggers the call to updateReloadButton.
MozReview-Commit-ID: BQL0RlvnCOo
--HG--
extra : rebase_source : c7d38192e87a5f69ef796d2c6d4dd3cc9f839bb3
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
--HG--
extra : rebase_source : 06bdb912d2d18f8121b8ff843610e5c5534b513c
It seems `doCommand` runs through a different codepath than just clicking the checkbox,
and as a result the outcome of the command handler is different that way.
This aligns the automated test closer to what happens when you 'manually'
click the checkbox, and fixes the bug in the command handler.
MozReview-Commit-ID: ACxRUxB35px
--HG--
extra : rebase_source : 7bc6d048d4ff6061aae6289e26f2b298820ed5ec
This was inadvertently removed when the preference attribute was removed to clean up a race condition.
MozReview-Commit-ID: 8yNPMwkGS3u
--HG--
extra : rebase_source : f6381588a47bc0bbd9c2b087ded55a85d131ec03
This mostly changes "cookies" to "cookies and site data" and amends a few
other details.
MozReview-Commit-ID: 97xTSQPw2DA
--HG--
extra : rebase_source : 63ceb2e11cad77441dbf11b298d6035081a29123
This is a regression from bug 1429593. The code that was added to enable/disable controls on the page
depending on whether an extension is in control was being run when the page opened, which overrode
the code which disables specific controls based on the current proxy setting. All that is needed is
to call that code (which is in gConnectionsDialog.proxyTypeChanged()) if an extension is not in control
after the new code that was added. This patch fixes that issue, and includes a test verifying that
the manual controls are not enabled when the screen first opens.
MozReview-Commit-ID: 7jpp1wewZ2k
--HG--
extra : rebase_source : 3bd13747ba9ba95fe50bce83a583af387352f8ef
Restore it to be <richlistitem>s so that nsAccessibilityService can produce
correct accessibles.
MozReview-Commit-ID: 1QiGyKPNifZ
--HG--
extra : rebase_source : 4d13ea216a88bb4a0272ac756dba2d50216fca35
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
--HG--
extra : rebase_source : 333d6165c74d6ff664cd3d603c5d834bfbde4326
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
This adds a dedicated test for showing and deleting cookies in site data
management as well as amending tests for sorting, grouping, etc.
MozReview-Commit-ID: 59mN3uASwPP
--HG--
extra : rebase_source : 04fdb5c952a676cc99d73f2c7dfa54300682b977
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
--HG--
extra : rebase_source : 98eea84efb2b90068bf0d106321d8af64afd1f77
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
--HG--
extra : rebase_source : 574aa329069f80e0beb52d1fd15f43e65a548c5c
extra : amend_source : a817fa4691c520eafaef808531b10581d09aeb14
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
--HG--
extra : rebase_source : bf5a52b39c40012058a22ed204ec947b5b8679da
extra : source : a1b90c54c94ca4fc81da9565bf0ef7fce661ce25
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
--HG--
extra : rebase_source : 07b660b7cf094b41ef4d3ca260a57341c349e488
extra : source : a1b90c54c94ca4fc81da9565bf0ef7fce661ce25
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
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
--HG--
extra : rebase_source : 4ec0ce408eae2b654265a864d25a4d2078e86c05
extra : source : a1b90c54c94ca4fc81da9565bf0ef7fce661ce25
This reverts the change introduced in bug 1394053.
Google has made the download protection lists available to everyone
and so we no longer need to restrict the download protection feature
to official builds.
MozReview-Commit-ID: CQcG5Ip1mDV
--HG--
extra : rebase_source : 55ff4f1e5a09e3c83ad9b24b2eb44789834b2357
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
MozReview-Commit-ID: IrtGJFtWPPj
--HG--
extra : rebase_source : 4098e79c532e57acc2d6e48ae496be1d0e6a9f9f
In preferences tests, all calls to waitForEvent function defined in
browser/components/preferences/in-content/tests/head.js has been replaced with
calls to BrowserTestUtils.waitForEvent.
Since we are no longer using the waitForEvent function defined in the
aforementioned head.js file, that definition has been removed.
MozReview-Commit-ID: IrtGJFtWPPj
--HG--
extra : rebase_source : 9d2fbb6194fa9127a9d559d98371dd60503c5e9e
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
--HG--
extra : rebase_source : 4cdee73b00b74e25c074e62a872d7b50a984cf8f
Binding the Preferences object to a "this" object was supposed to enable userChangedValue to access the DeferredTask instance that XPCOMUtils.defineLazyModuleGetter defines on the "this" object.
I thought that worked, because tests passed, but it turned out that no tests are exercising the branch within userChangedValue that references DeferredTask, which is only followed for pref form controls that specify "delayprefsave."
Only font controls specify that attribute, and there weren't any tests for changes to those controls. This patch adds such tests and then changes the way that DeferredTask is lazily retrieved and referenced to ensure it's defined as referenced in userChangedValue.
MozReview-Commit-ID: BPbGp55s9wC
--HG--
extra : rebase_source : 1851f88c6bed6d4315b3383f3756af863b6d6be5