This is a follow-up to bug 1429464 and a hack. Fortunately we could get
rid of it when bug 1392352 lands.
MozReview-Commit-ID: 4XVjObBPAMV
--HG--
extra : rebase_source : 7c170a3b88ce68860b41b516d66b7442cfeea686
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
This commit does several subtle things.
1: It changes ok() to opener.ok()
ok is not defined, we have to use opener.ok. This was not caught before because
this call is used to provide additional debugging information when a test fails.
Test didn't fail, didn't hit that line.
2: It disables the call to opener.ok() we just fixed.
As the comment there describes, we expect that function to fail, so we don't want
to assert(false).
3: It inverts failures to successes if only the reduceTimerPrecision pref is set
MozReview-Commit-ID: lpKKhJoDs6
--HG--
extra : rebase_source : 0d29f2b6061526abe989c4b58397bb78631cec7b
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
We were not correctly setting the menulist value for default popup permissions,
which went largely unnoticed so far because the user had no way of actually setting
these permissions explicitly. It might happen with policy engine in the future
and so we should fix this.
MozReview-Commit-ID: 1VQc1NRGGX
--HG--
extra : rebase_source : 91dd30d11913316e1fc50c09b3ca37ae6430c938
This removes all the homepage-related code. All the cases where we advance the wizard straight to
the homepage wizardpage now go straight to the 'start migrating' page (the 'point' was skipping
earlier pages that allowed users to select items).
The brand bundle was only used by the homepage code so is also being removed.
MozReview-Commit-ID: I9nSU2IMkQz
--HG--
extra : rebase_source : da803ed67b443cb164f2bc55550bfd7c107fa916
The promisePanelEvent function was unreliable because it did not raise an error if the provided panel did not exist, which caused one of the callers to ignore a missing panel silently. All the callers have now been updated based on whether they expect the panel to exist or not.
MozReview-Commit-ID: AGT4rHls4OB
--HG--
extra : source : 0857964174624b1cf3d4ea3ffa94ba21b090788a
extra : intermediate-source : 29972a52d5c4829eb7fd662792836c934b1d11d8
This commit does several subtle things.
1: It changes ok() to opener.ok()
ok is not defined, we have to use opener.ok. This was not caught before because
this call is used to provide additional debugging information when a test fails.
Test didn't fail, didn't hit that line.
2: It disables the call to opener.ok() we just fixed.
As the comment there describes, we expect that function to fail, so we don't want
to assert(false).
3: It inverts failures to successes if only the reduceTimerPrecision pref is set
MozReview-Commit-ID: lpKKhJoDs6
--HG--
extra : rebase_source : 01386c0a91dd5262cbee95ecbd0be6df5539006a
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
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
In bug 1426721 we added a bulk interface for importing logins, which
works in a background thread. This patch cleans up the single-login
interface and updates the remaining usages to consume the bulk
interface.
MozReview-Commit-ID: IziLXkO5dxQ
--HG--
extra : rebase_source : 7b2df904fde5ec0abeb7d30633b0dd819de0cc9e
A top-level array (i.e., if a policy directly requires an array) won't be affected by this problem, because if the array is missing, that means that that policy is not present, so it will be ignored.
However, this can affect an array that is expected inside another object, for more complex policy types (like the popups permission which accepts both an 'allow' and a 'block' array of URLs.
In the future, we should implement the 'required' property as defined by the JSON-Schema standard, but there's not a strong use case for it yet, so let's do the simple solution for now
MozReview-Commit-ID: 4MTBTsPYlX8
Some tests do a sanity check for features at the beginning. This works fine for a single test, and also from one test to another which are usually activating different policies. But this fails when the same test runs more than once, because the engine was left at the end in a state where that same policy was active.
Note that this does not cover all the clean-up that a test must do to properly run more than once. For example, locked prefs are left locked, because the engine does support reversing all the policy code that ran. We might add more auto-reversal support in the future, but for now it's up to each test.
MozReview-Commit-ID: KZ2LeKFTC0A
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
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
This is part of the work to remove XUL overlays. This overlay is only
used once and can be inlined.
MozReview-Commit-ID: 1R0pZqpVTIZ
--HG--
extra : rebase_source : 8a3eaa8119981616160a58e316cadb49ac78f238
- bundle_browser_region is already unused so that's just removed.
- After the previous changeset, bundle_browser is referenced only in utilityOverlay.js,
where it's used for the context menu's "Open Link In New Container Tab" submenu.
By updating that one consumer to use Services.strings.createBundle directly we can
remove all instances of the bundle_browser node (overlay and otherwise), and chip
away at the baseMenuOverlay file.
MozReview-Commit-ID: KylUwBRNciS
--HG--
extra : rebase_source : 0ba6478a55111e77a77da40c15d74d9c6c9339c6
This will allow us to not rely on an actual <stringbundle> while still avoiding a mass rewrite
of code that accesses gNavigatorBundle with the more awkward API exposed by gBrowserBundle.
MozReview-Commit-ID: 2B4smbo1xZP
--HG--
extra : rebase_source : 0f2eef9178cb61802f158efe88b82a723f5e082e
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 moves all the functions that manage/change the UI because of extensions being in
control of certain preferences to a separate file, so it can be included in SubDialogs.
MozReview-Commit-ID: 7OkEn478Pus
--HG--
extra : rebase_source : b3a299e965f726204204d104e07517c4520d766d
Removed a fallback import from a legacy FHR file when there is no valid ID in the DRS file.
This commit is related to bug 1431544
MozReview-Commit-ID: AACq7InWJpy
--HG--
extra : rebase_source : c48bf48addc515b9d86f22dd4e8ad5a066ebc76a
This cleans up all tests that were not moved into the sanitize directory
as part of the previous commit, but still use sanitize.js
MozReview-Commit-ID: 1CVa0ByVYDk
--HG--
extra : rebase_source : 457e8ba671d3f5577c1ce3fe8536c82096a7f36b
We're changing the way sanitize.js/Sanitizer.jsm works and need to adjust a lot of tests to that.
I'm using this opportunity to also move the sanitization tests into their
own topical directory and out of b/b/c/test/general.
MozReview-Commit-ID: GHOqr4hT52b
--HG--
rename : browser/base/content/test/general/browser_purgehistory_clears_sh.js => browser/base/content/test/sanitize/browser_purgehistory_clears_sh.js
rename : browser/base/content/test/general/browser_bug409624.js => browser/base/content/test/sanitize/browser_sanitize-formhistory.js
rename : browser/base/content/test/general/browser_sanitize-passwordDisabledHosts.js => browser/base/content/test/sanitize/browser_sanitize-passwordDisabledHosts.js
rename : browser/base/content/test/general/browser_sanitize-sitepermissions.js => browser/base/content/test/sanitize/browser_sanitize-sitepermissions.js
rename : browser/base/content/test/general/browser_sanitize-timespans.js => browser/base/content/test/sanitize/browser_sanitize-timespans.js
rename : browser/base/content/test/general/browser_sanitizeDialog.js => browser/base/content/test/sanitize/browser_sanitizeDialog.js
extra : rebase_source : 10577846b8a407d12f7459b270a5c5573cd425ad
This replaces all non-test usage of sanitize.js or legacy Sanitizer.jsm
to use the new Sanitizer.jsm module which does not hold internal state
and instead receives all configuration through function arguments (or by reading prefs).
MozReview-Commit-ID: KitMVptuIG3
--HG--
extra : rebase_source : e6696a5246db3f6ef9dd25aeab5d239d7fc7f8e3
This was initially removed when we added support for setting the favicon
ahead of parsing the page for newtab-like pages. Turns out we need it in
some scenarios, such as navigating back and forth or duplicating the tab.
MozReview-Commit-ID: HuMeEnqpLLB
--HG--
extra : rebase_source : 05745b3e4b911407875fc50e5a9a3f1a67fbafd5
Added support for color.button_background, color.button_background_hover, color.button_background_active
MozReview-Commit-ID: F0EcTLMWE6h
--HG--
extra : rebase_source : dfd25d55ffb2a8d0a671c22b6212a8c4340d68d4
We'll stop dispatching keypress events on web contents for conforming to spec of
UI Events. Some existing tests assumes that keypress events are fired even
when non-printable keys are pressed.
This patch makes them check the pref,
"dom.keyboardevent.keypress.dispatch_non_printable_keys_only_system_group_in_content"
and only listen to keydown event instead of keypress even if the pref is true
and expected key event is not a printable key press.
MozReview-Commit-ID: 6bKoK7dsB0l
--HG--
extra : rebase_source : b3705b0814d5690e00208d0d3315f09f886c6f26
Added support for color.button_background, color.button_background_hover, color.button_background_active
MozReview-Commit-ID: F0EcTLMWE6h
--HG--
extra : rebase_source : 663356d0a518ac9d64319d15a9268f923add6a6b
We now know that worker restarts are rather frequent and we've had reports that
are certain to point at us forgetting to properly re-initialize the worker.
This takes care of this by factoring the init flow into its own method and setting
the flag when a failing worker is terminated.
MozReview-Commit-ID: G5jccjxkBsF
--HG--
extra : rebase_source : 8ca25f5771294697d1875b09b671de2660ef79d5
We now know that worker restarts are rather frequent and we've had reports that
are certain to point at us forgetting to properly re-initialize the worker.
This takes care of this by factoring the init flow into its own method and setting
the flag when a failing worker is terminated.
MozReview-Commit-ID: G5jccjxkBsF
--HG--
extra : rebase_source : 8ca25f5771294697d1875b09b671de2660ef79d5
The phishing overlay was only used in one place and could be inlined. This
was slightly less straightforward as the original overlay was used on
browser.xul, but the elements it overlayed are defined in include files and
in another overlay (baseMenuOverlay.xul). Since baseMenuOverlay.xul is used
by other windows, the "hidden" attribute had to be added to the phishing
menuitems so they didn't show up in the other windows e.g. places.
MozReview-Commit-ID: 6t0MpWmgyGg
Signed-off-by: Brendan Dahl <brendan.dahl@gmail.com>
--HG--
extra : rebase_source : 09a691d24cec78c72111a9d3e476c8c80e097178
This allows the ViewShowing event for the main view to prevent the panel from opening. It also avoids setting up the main view if the panel is not opened.
MozReview-Commit-ID: Ks9fQMxjhGu
--HG--
extra : rebase_source : 6ce5aba338a77fb70b7a4bf8bb38ed35bb0d992b
extra : amend_source : f6480289fb1b7743c945b1252228500f663435df
The promisePanelEvent function was unreliable because it did not raise an error if the provided panel did not exist, which caused one of the callers to ignore a missing panel silently. All the callers have now been updated based on whether they expect the panel to exist or not.
MozReview-Commit-ID: AGT4rHls4OB
--HG--
extra : rebase_source : f95967444ffbd2bbdc99560104845af31b71e94b
We're not actually using it, and it messes up with the zone allocator in
mozjemalloc after fork(). See the lengthy analysis in
https://bugzilla.mozilla.org/show_bug.cgi?id=1424709#c34 and following.
--HG--
extra : rebase_source : c58e13b897dde7b32d83c43fbb2a04a0db3a5dc9
We have to keep track of the focused element while we remove the richlistbox element temporarily.
MozReview-Commit-ID: AePydUyyUS7
--HG--
extra : rebase_source : 1dbab87a07a4d95780e0abf29efec94ea73344cf
extra : amend_source : 6e685a648e0ba674eba791e1dc7138f67bd7f1e0
Now that writing the .purgecaches sentinel is done by |mach build|, we
can remove it from Make. In addition, we can cull the now-unused
app-rules.mk \o/
MozReview-Commit-ID: 6CnAqLeZwzB
--HG--
extra : rebase_source : 2a5b67e723f8e1654627e6e6f26704f6a4e57706
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
Fairly trivial. This was breaking for the test_refresh_firefox
test in beta, since the code which calls this is only active if
certain branding strings are present.
MozReview-Commit-ID: 3CkosXHgoMm
--HG--
extra : rebase_source : b027b12f3f09a8114ccf32c767262a32543b3a74
As of bug 1430036 it was only set when building on CentOS, and as of bug
1432398, we don't have CentOS-based docker images anymore.
--HG--
extra : rebase_source : 5ade9bee773bca3283cfdb9d69209033fe82253f
The binutils we currently use as part of our GCC toolchain artifact
doesn't understand some relocations in the CRT objects on Debian
stretch, making the embedded CRT objects from bug 1427344, which we want
to remove in bug 1431251, necessary.
OTOH, there is no benefit from using our GCC toolchain artifact for host
compilations on those builds. In fact, Android builds, which are in a
similar position, being built on Debian stretch and being cross-builds,
don't care to use our GCC toolchain artifact.
It's arguably a good thing that those builds are not tied to the version
of GCC we use to build Firefox for linux, so let's remove this
dependency.
--HG--
extra : rebase_source : a80d4e4fb01a4862b844ebde0c521a635f462c0a