The hgwatchman project has been renamed to fsmonitor and has been moved
into Mercurial core, as of version 3.8.
Accordingly, for Mercurial >= 3.8, we shall skip installing hgwatchman
but just set fsmonitor in hgrc file instead.
DONTBUILD (NPOTB)
MozReview-Commit-ID: 426rla5riCM
--HG--
extra : rebase_source : 359eb135a2c16361125da6f1fe97eedf9434032e
TaskbarTabPreview object will be released by GC. So when Disable method is called, window may already destroyed. So we should check whether window is destroyed.
MozReview-Commit-ID: MGz3JmDh37
--HG--
extra : rebase_source : 43a859cbcb729718b59745182c94ef3688a44f0f
When building a desktop version of Firefox with MOZ_LINKER enabled, the
zlib library is necessary for mozglue. The mozglue library is statically
linked to programs on desktop builds of Firefox, and the required setup
for those things is done in the GeckoProgram template, along with adding
the necessary zlib linkage.
Not sure how events went through but the current definitions in
mozglue/build/moz.build and config/external/zlib/moz.build make it that
USE_LIBS += ['mozglue'] currently implies zlib being linked in that case
without it being done explicitly in GeckoProgram, so remove that.
So far, we relied on the module being copied over in the virtualenv, and
the module itself would try to find config.status in parent directories
of its own location. Unfortunately, this falls short when the source
tree's build/ directory appears early in the sys.path.
With this change, we don't copy the module to the virtualenv anymore,
and try to find config.status in parent directories of the python
executable, which, when running from the virtualenv, will be equivalent
to the current behavior.
The previous code checked:
if (env.startsWith("MOZ_DISABLE_SWITCHBOARD=")) {
if (!env.endsWith("=")) {
So it would not pass with the empty String but my previous revision permitted
the empty string.
Practically speaking, I don't think it matters because this is only used in
remoteautomation.py where the value is 1, but better safe than sorry.
MozReview-Commit-ID: DLtmvWlQYs7
--HG--
extra : rebase_source : 3c96cf81f729911bfefcc103f46068bd9b8fb202
- Fix a typo in media.gmp-eme-adobe.version pref strings.
- Update reset gmp script call to be from content context. This
would fail if done from the chrome process.
- Update reset gmp script to use new requestMediaKeySystemAccess
syntax.
MozReview-Commit-ID: FzDgkOWQF9A
--HG--
extra : rebase_source : 5a3082978bd80d994320017c6917e121fa40a742
Previously, all `PushNotifier` methods checked the process type, and
either called `Notify*{Workers, Observers}` or sent an IPDL message.
The message handlers then called back in to `PushNotifier` from the
remote process.
This was clearer when we only sent worker event notifications to the
content process, and fired all observer notifications in the parent.
It became more complicated once we started notifying observers for all
subscriptions in both processes (bug 1266433). This makes it harder to
see omissions; for example, "push-subscription-modified" isn't
currently forwarded to the child, but "push-subscription-change" and
"push-message" are.
This patch moves the remoting code into `PushNotifier::Dispatch`, and
adds a base `PushDispatcher` class. Each notification type subclasses
this class and implements logic for sending messages and firing
observers and worker events. It's more code, but a bit easier to see
which methods are called where.
MozReview-Commit-ID: 7Q0eD7qXOrW
--HG--
extra : rebase_source : c69acb95a0cb5470cf1c804639971be41b976cc2
Now that digits have been filtered out of the message manager message
names to avoid creating thousands of similar keys, we can reenable the
telemetry by renaming it. Also, update the description to address
bsmedberg's comments, and add me to the list of alert emails.
There are a huge number of different message manager messages with
names of the form "ublock0:sb:{N}", where {N} is some number from 1 to
over 1000. Having so many different keys seems to cause problems for
telemetry and makes it harder to tell how many messages of each type
there really are, so this patch combines them by eliminating any
digits. It will also help for the webdev tools that use channels with
names like "debug:server1.conn5.child1:packet". This will create some
ambiguity (eg there are some messages of the form "ublock:sb:{N}"),
but that should be a minor issue.