On macOS, the paths for the special directories `GreD` (Resources) vs. `GreBinD`
(MacOS) are different. On other platforms, they are the same.
With scalar loading for artifact builds, we need to load a file from
`Resources`, so `GreD` should be used for this case.
MozReview-Commit-ID: 91JFwOISQCk
--HG--
extra : rebase_source : d94df1acc4c7b9d6fe217fb0621950eb2c53351d
Before, we would initialize LRUCache on the first instance of
calling the Timer Precision Reduction functions. We would both
allocate and initialize it, and call ClearOnShutdown.
ClearOnShutdown can only be called on the Main Thread, but it
just so happened that we always did that, so there was no
problem. Now that we are not calling precision reduction for
system callers, we were initializing on a non-main-thread and
we need to avoid that.
In the future, we could reduce memory use IF we are not using
the timer precision reduction functions by figuring out how
to initialize this lazily but still on the main thread. For
now, because we are using the timer precision reduction
functions, doing so would not save us any memory.
MozReview-Commit-ID: 6YGeAlCPReZ
Because plugin state in the content now contains blocklist state, and is updated
when the blocklist updates, we don't need to ask the parent if we're checking
blocklist state. All the consumers should now be asking the plugin code directly,
so we can stub out the last API here. We should look at removing the content side
of this service entirely, but that's something for a follow-up bug.
MozReview-Commit-ID: DE8s8RwT42r
--HG--
extra : rebase_source : 06fbc304e99679f55c7cdc52404cd138221feca3
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
We currently have a few probes which measure how long tab switch
spinners are displayed, but we have little information into their
source. In diagnosing and attempting to lower the number of
spinners that users see, we could use more information about
their source to help prioritize and narrow in on regions of code.
MozReview-Commit-ID: Cw4ejOM9ZSl
--HG--
extra : rebase_source : c44307ab1195eaeda43e10302e10756b366a2740
Like PAGELOAD_IS_SSL, it is very useful for the ecosystem to monitor
CERT_VALIDATION_SUCCESS_BY_CA for release populations. See websites like
https://crt.sh/mozilla-certvalidations for examples.
This patch does a few of the things requested in Bug 1369747 like adding
alert emails and a bug_numbers field. It also sets "releaseChannelCollection"
to "opt-out".
MozReview-Commit-ID: FMHOTqvaJKy
--HG--
extra : rebase_source : b7b94ed8d00bbc923040477caaa35228b688e9fe
Addon's "Preferences" tab was opening up to the right of ALL tabs rather than next
to the current tab. This behavior has been corrected, and the aforementioned
tab is now placed relative to the opening tab.
MozReview-Commit-ID: APiUR9VkEEt
--HG--
extra : rebase_source : 3b274b9663ae9084c5d3b1823cc044b6adf629b3
console.assert keeps the same semantics as NS_ASSERT in that it doesn't throw an exception,
but a lot of the places code was using it in a way that would be better served by throwing
an exception when the condition is false.
MozReview-Commit-ID: DEF5HSfYO36
When the BHR wants to report a tardy thread, it hands off the work of
getting a stacktrace to a helper thread. The helper threads used are in the
Stream Transport Service threadpool, which has a default limit of 25
threads.
This has a bad effect when we are in a severely compute-resource constrained
situation. Then, many threads will be late, and up to 25 STS worker threads
will be employed to do unwinding, a potentially expensive operation. This
further restricts the compute resources available to progress the rest of
the system.
Another effect is that the unwinder work will compete against the "real" STS
work for the 25 workers, potentially further slowing forward progress.
This patch replaces the use of the STS thread pool with a single nsThread
dedicated to unwinding/reporting hangs.
--HG--
extra : rebase_source : 0486be970633512e46ac030c5373ed7dfa0e7cb3
This retains support for installing unpacked dictionaries, since Hunspell only
supports loading dictionaries from ordinary filesystem paths.
Unpacked extensions are no longer supported on production, except during
development. WebExtensions have no support for the unpacked flag at all, and
specially signed legacy extensions are forbidden from using it, so there's no
point in maintaining support for this install code. Or, more importantly, for
running a nearly complete duplicated set of tests in order to exercise it.
MozReview-Commit-ID: 1fKVgSelJQ8
--HG--
extra : rebase_source : a2e9086a3d050b66eab9c17fff9c2f7189911832
extra : amend_source : da8f6425ec74a824a3d19f13bb4eb51980cd64c1
In some cases, the rejection stack from `PromiseDebugging` may be null. If the
rejection reason was an Error object, use its `stack` to recover a meaningful
value. This greatly improves diagnosing test failures due to promise rejection.
MozReview-Commit-ID: IpE2kGoFcpx
--HG--
extra : rebase_source : f3b0ca4a27d0fa8df11b41ae93954478c199fef4