The lazy loading is a little more complex because we want this to be a constant
in the scope so extensions can't trivially replace it. This also changes the
test to be more like the proof of concept from bug 1244248.
I took the opportunity to promisify a bunch of things which ultimately made the
verifySignatures code nicer.
MozReview-Commit-ID: 2P890uRY1Si
--HG--
extra : rebase_source : 5fbccfa949089db0c7f3dbb341532ba335a4d6bc
A missing dependency in "nsTypeAheadFind.h" is also fixed to allow the removal of the include files from "nsToolkitCompsModule.cpp".
MozReview-Commit-ID: EefZA9bEUW0
--HG--
extra : rebase_source : 8ddfaf72f2b89c6e906561710045ec677e46da79
Accumulates the time in between running unlabeled runnables in a histogram. This
measurement will be useful to see how much of a win the cooperative scheduler
will be, assuming we label no more runnables.
MozReview-Commit-ID: 9lgoGJcXLP9
This patch fixes the upload/packaging build step for Thunderbird beta builds
MozReview-Commit-ID: K2qcZ4pLvtN
--HG--
extra : amend_source : f16a6747c0260242442a4aa022be1d47a22ab30b
Remove suggested and enhanced tiles along with related campaign, frequency-cap, inadjacency, pings, preferences, strings, styles, tests.
MozReview-Commit-ID: FkjaSpSFQHu
--HG--
extra : rebase_source : 1c58ac542180f0abb290639ec1c61b9edf3d0a51
The lazy loading is a little more complex because we want this to be a constant
in the scope so extensions can't trivially replace it. This also changes the
test to be more like the proof of concept from bug 1244248.
MozReview-Commit-ID: 2P890uRY1Si
--HG--
extra : rebase_source : 6eaa3aabde262b0e03f0e664b15fa50e53d75c5a
This patch uses the new Photon animation curve for notification bars as well
as supporting `toolkit.cosmeticAnimations.enabled` to disable the animations
on notification bars entirely.
MozReview-Commit-ID: AHSQR32g6hf
--HG--
extra : rebase_source : 9b643a758db07791dbda12f7e6383f193f3fa698
This patch includes two test cases:
1. Apply an empty update through Classifier interface, which is the normal use case.
2. Apply an empty update through LookupCacheV4::ApplyUpdate, this ensure update algorithm is
correct when applying an empty update. This scenario actually shouldn't happen in
normal use case because it will be skipped by Classifier::CheckValidUpdate.
MozReview-Commit-ID: 9khsuVatX0u
--HG--
extra : rebase_source : 8db87dd2b8b4aec4546257e9f06dcc839b2ea181
It schedules the ping to be sent on new profiles after 30 minutes
from the Firefox startup. The ping is eventually sent at shutdown
if the scheduled time wasn't reached.
To reliably prevent sending the ping more than once, the "session-state.json"
file is used to keep track of the "sent" state.
The "new-profile" ping is protected behind a pref, disabled by default
in this patch.
MozReview-Commit-ID: 4g4lPRXe9q6
--HG--
extra : rebase_source : d32e93ac63a2f0c23a3d0690eca4a1e83f57c3e3
I see the following JavaScript warning in stdout when I run Firefox tests from the console.
JavaScript warning: resource://gre/modules/addons/XPIProvider.jsm, line 2970: String.localeCompare is deprecated; use String.prototype.localeCompare instead
MozReview-Commit-ID: ERiTd3rQ4Wc
--HG--
extra : rebase_source : bf7e8d28b652f17ae6c8ae140828acbd73bfc0e0
resetDatabase() is used to clear out the Safe Browsing database and cache in tests.
Since bug 1333328 however we can no longer rely on updates clearing the cache.
There are two solutions to address this issue:
1. resetDatabase() calls another test-only function: reloadDatabase(). Since the cache
is in memory, reloading the URL classifier will automatically clear the cache.
2. During an update, remove cache entries which are not in the database.
I prefer taking the first one because if we implement the second
approach, an update will take longer since we need to check if each prefix
in the cache can also be found in the database. I think this is not necessary
because prefixes not in the database will eventually be removed when they
are expired.
MozReview-Commit-ID: BjsDKDMr205
--HG--
extra : rebase_source : d4cf8d9876d1427a7917fc74ecb7bc1bf91bf371
The probes needing to record in gpu were determined by listing the probes that
submitted data for those measures on Nightly on April 18.
MozReview-Commit-ID: 85nQA8rCH1p
--HG--
extra : rebase_source : 8ed93a90955c665f048d215769c4ef286f45bf0e
We now have code that unconditionally requires the rust
compiler and are committed to adding more. Remove this
last vestige of conditional support.
MozReview-Commit-ID: EK6FBnAbR
--HG--
extra : rebase_source : 6efda10a74f9ca0482304c2b1ffe6941e42138f8
The probes needing to record in gpu were determined by listing the probes that
submitted data for those measures on Nightly on April 18.
MozReview-Commit-ID: 85nQA8rCH1p
--HG--
extra : rebase_source : 58fd8cd7af623e1b6de9831af2cf66e6880dba7c
__define{Getter,Setter}__ are deprecated, and are not defined on
NonSyntacticVariablesObjects, so these calls get in the way of sharing
globals between different .jsms. Probably only the DownloadUtils.jsm
change is really needed for that.
configurable and enumerable are both set to true to match the existing
behavior. If enumerable is set to false, then tests fail, because some
of the getters overwrite the getter with a regular property.
MozReview-Commit-ID: 1OZF45fIAQ
--HG--
extra : source : 96dd2e2d8d1677fb04c98bb3a063df32478fbc00
Cu.isModuleLoaded is more direct, and also the current method will
break if jsms begin to share globals, as in bug 1186409.
This patch is by billm from bug 1186409.
MozReview-Commit-ID: KoHMTJpmHg2
--HG--
extra : source : 1f18d8c7210c75275a4ba49a0bd40cb5c81ea286
Right now notifications displayed in non-focused windows are
causing that window to be focused. This is annoying. We could work
to make the doorhangers not focus the other windows, but a simpler
solution is to just not show the doorhanger until the window is
focused. This has the added benefit of ensuring that the doorhangers
entry animation is seen by the user, increasing the likelihood that
they will notice it.
Additionally, some existing tests involving extra windows were
refactored. I stripped the old tests of their extra windows and
created new tests specifically to test the behavior of background
windows. These tests were modeled off of the background window
tests of PopupNotifications.jsm, which create a new window knowing
that this will cause the existing window to be the background,
rather than explicitly manipulating the focus of the two windows.
MozReview-Commit-ID: 1fjrDOhEKCw
--HG--
extra : rebase_source : 954ace7e43da90fcee3da2d70c4bdbcda8456d77
Added a method in History to filter by host and timeframe, which is designed
to act as a replacement for `RemovePagesByTimeFrame` and `RemovePagesFromHost`
in the old API. The `filter` object accepts both a host argument, as well as
a timeframe, and filters as per one or both of them.
This also moves certain code (the method `validatePageInfo` and methods it
uses) from History to PlacesUtils such that we can use it for testing as well,
and modifies the method to take another parameter which decides whether
the visits inside the pageInfo need to be validated as well (since the pageInfo
returned from History.jsm::`remove` and History.jsm::`removeByFilter` do not pass
a visits array in their callback functions.
Shifts `ensureDate` and `isValidTransitionType`(now renamed to `isValidTransition`)
inside the history object.
MozReview-Commit-ID: EQAHmjf7131
--HG--
extra : rebase_source : d5992a1bd3c297c84dd0ecbf47111e8f914a58a0
This scan no longer serves a useful purpose in production, now that mandatory
extension signing requires manifest changes after update.
MozReview-Commit-ID: 817qRuyzL5P
--HG--
extra : rebase_source : bb85ac3c5da99e60e6b91267aea6779ad85f8c1b
This scan no longer serves a useful purpose in production, now that mandatory
extension signing requires manifest changes after update.
MozReview-Commit-ID: 817qRuyzL5P
--HG--
extra : rebase_source : 7c90c8319ee84fa0ea32d81e58a8af13281714d7
extra : source : 237268e3d9d2d269dbb555bed54470925d54aa88
The new telemetry tag is for probing the best IPC message pre-allocate size to avoid
realloc overhead. We only count those message size which is greater than 4096.
This tag integrates IPC_MESSAGE_SIZE and MESSAGE_MANAGER_MESSAGE_SIZE2 which
have both expired.
MozReview-Commit-ID: GjvuidGJ7pz
--HG--
extra : rebase_source : 1da13b3f2b5b042d0445abd6051993e2fb317f93
The background page do not need to use the AddonManager to set its preferred debugging global
anymore (and it would not be able to use it from the extension child process).
MozReview-Commit-ID: 2IAxvCjDKvl
--HG--
extra : rebase_source : 5d39269d73f4b6582efe1af10e0575aa6bd52db6
The background page do not need to use the AddonManager to set its preferred debugging global
anymore (and it would not be able to use it from the extension child process).
MozReview-Commit-ID: 2IAxvCjDKvl
--HG--
extra : rebase_source : eb10f2c71e74f27a0151459a53f5ce6269392155
This change prepare the WebExtensions internals to the changes applied to the
addon debugging facilities in the other patches from this queue.
In ExtensionParent.jsm, a HiddenXULWindow helper class has been refactored out
of the HiddenExtensionPage and then reused by both HiddenExtensionPage and
the new DebugUtils object.
The DebugUtils object provides the utility methods used by the
devtools actors related to the addon debugging, which are used to retrieve
an "extension process browser XUL element" (a XUL browser element that has been
configured by DebugUtils to be used to connect the devtools parent
actor to the process where the target extension is running), and then release it
when it is not needed anymore (because the developer toolbox has been closed and
all the devtools actors destroyed).
The DebugUtils object used the HiddenXULWindow class to lazily create
an hidden XUL window to contain the "extension process browser XUL elements"
described above (and the HiddenXULWindow istance is then destroyed when there
is no devtools actor that is using it anymore).
MozReview-Commit-ID: 31RYQk1DMvE
--HG--
extra : rebase_source : f1fd954d79593107b4542dfbb655abea05e9bd98
This change prepare the WebExtensions internals to the changes applied to the
addon debugging facilities in the other patches from this queue.
In ExtensionParent.jsm, a HiddenXULWindow helper class has been refactored out
of the HiddenExtensionPage and then reused by both HiddenExtensionPage and
the new DebugUtils object.
The DebugUtils object provides the utility methods used by the
devtools actors related to the addon debugging, which are used to retrieve
an "extension process browser XUL element" (a XUL browser element that has been
configured by DebugUtils to be used to connect the devtools parent
actor to the process where the target extension is running), and then release it
when it is not needed anymore (because the developer toolbox has been closed and
all the devtools actors destroyed).
The DebugUtils object used the HiddenXULWindow class to lazily create
an hidden XUL window to contain the "extension process browser XUL elements"
described above (and the HiddenXULWindow istance is then destroyed when there
is no devtools actor that is using it anymore).
MozReview-Commit-ID: 31RYQk1DMvE
--HG--
extra : rebase_source : 82a71189b359acecd100e94e3c48ef344dbb48c4
GeckoAppShell.scheduleRestart was called from XPCOM toolkit when we
needed to restart after the Gecko thread exits. But because we made the
"Gecko:Exited" event contain a "restart" flag, we can handle that
entirely in Java now, so we don't need to call
GeckoAppShell.scheduleRestart anymore.
Previous design allows us calling resume/block from both front-end and back-end,
it's not easy to know who called these operations.
So move all these logic to frond-end side, it's more clear than before.
One important thing is that we should block tab before loading the content.
If we block the tab after loading, the media might not be blocked because it had
already started (that is one situation I observed from test).
The value of block state would be stored in the outer window, before media want
to start, it would check this value to know whether it can start playing or not.
---
In addition, introduce new attribute "media-blocked".
The "media-blocked" attribute indicates that whether the tab is allowed to play autoplay media.
The "activemedia-blocked" attribute indicates whether the tab has blocked the autoplay media.
MozReview-Commit-ID: FnNh3zmItxo
--HG--
extra : rebase_source : cdc890c0c47a4a03ea8dbbdfee24c66b52945c60
The "blocked" attribute is too general to indicate the real usage, so rename it
to "activemedia-blocked".
This attribute indicates that whether the tab has blocked the autoplay media.
MozReview-Commit-ID: EAmq6OuBYjq
--HG--
extra : rebase_source : e8e9321854b80736f0959fbfecbc8bf9a83b0712
Importing the blocklist-updater module on each notification in nsBlocklistService
could cause us to periodically jank the browser UI.
This patch now lazy loads as many dependencies as possible.
MozReview-Commit-ID: HBGjSJi5PwE
--HG--
extra : rebase_source : 4a7c18fe64b810f54d52eee07883d67837b297d3
The "platform" chrome flag requires an irrelevant "content" chrome
manifest entry, while it's only used for locales. It only has exactly
one use, which can actually be replaced by uses of the "os" flag.
Note, we're doing something similar with the "os" flag for skins in
e.g. browser/extensions/pocket/jar.mn.
Unfortunately, for determinism reasons, the chrome manifest entries from
jar.mn are sorted (per bug 982075), so keeping global-platform/unix
would leave it appearing after /mac, and would override it on mac
because of the lack of "os" flag on the /unix entry (we can't put "os"
flags on that entry because we can't do something like os!=Darwin &&
os!=WINNT). So we move it to /gtk such that it always comes before /mac.
--HG--
extra : rebase_source : aaace8147ea54f74aef8a7b2314ad022e9f9be23
Reword the `llvm-config` detection error message to recommend setting the
LLVM_CONFIG env var, like we do for the bootstrap path. This avoids exposing
`clang` as well, so the compiler won't be changed.
MozReview-Commit-ID: CVNJ2bX2POa
--HG--
extra : rebase_source : fedfb95e105f88fec08689ae3c69a841f3b52173
The login manager searching logins for autofill may trap the user
in an infinite loop of master password prompts until the user enters
the correct master password. To prevent that, we're adding a timeout
to showing the master password prompt for autofill after it was last
cancelled.
MozReview-Commit-ID: JcmTDU6CKKA
--HG--
extra : rebase_source : 6f4d2c59360963f53972b812d999756637434415
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
It seems like the server-side keyring is getting deleted somehow. This
causes syncing of the keyring to fail. We haven't completely
fixed the root problem yet, but this adds logging to try to flag
down the dangerous operation of deleting a bucket to make sure we
aren't doing that by accident. We also try to recover from the
server-keyring-was-deleted situation by wiping all storage.sync data,
the same as if we found a keyring that we couldn't decrypt.
MozReview-Commit-ID: JMB0IxApbGq
--HG--
extra : rebase_source : 54982a374aa5c7d7e60e8175b99734c672b91799
Use MOZ_FORMAT_PRINTF in toolkit/mozapps/update, and fix the one
erroneous printf that this detected.
MozReview-Commit-ID: 5dzyMOZwNDG
--HG--
extra : rebase_source : b26942181d52b356702c039bcace11dbf900a3d1
We want to see if we can drop support due to web pages not using it.
Edge and Safari already don't support it, and Chrome reports that usage
is low enough that they're willing to drop it. But telemetry doesn't
tell us about web usage if we're triggering it via our own internal
code.
MozReview-Commit-ID: 5YBfhQJExHC
--HG--
extra : rebase_source : fd359e3264ba96ef10617f4de767080c94b792fb