Usually, upload-symbols tasks run as part of the on-push graph; however, if a
push only touches platform-specific code, builds for other platforms may get
optimized out, along with the corresponding upload-symbols tasks. If release
promotion is triggered on such a push, we may end up shipping builds whose
symbols are missing from the symbols server, affecting downstream consumers
like crash-stats. To avoid this, ensure beetmover jobs (as an arbitrary
choice) pull in the upload-symbols tasks.
Differential Revision: https://phabricator.services.mozilla.com/D219768
Basically we were falling off a cliff where if we had a bunch of marks recorded
with a particular name, when trying to measure we would fill an array with all
of them only to return the last one. This just replaces that by iterating in
reverse and returning the first matching mark. Arguably we should be using a
hashmap or something here, but this is a quick and trivial improvement that I
think will resolve the reported issue.
Differential Revision: https://phabricator.services.mozilla.com/D199451
The problem here is that currently we mark incoming cross compartment edges
from uncollected compartments in two phases depending on the color of the
wrapper, but that color can change in between due to gray unmarking.
The patch does the simple thing of rescanning the incoming edges for black
wrappers after marking gray ones. This involves a little juggling of the
current mark color to ensure we can't mark black after marking gray.
Differential Revision: https://phabricator.services.mozilla.com/D219725
Currently, when a page enters BFCache, it updates the parent process
for the active BC; however, the page that is about to show will do the
same. These two operations are triggered in different processes with
different active id, they are racy and problematic.
This patch fixes the above issue by not updating the parent process
when a page enters BFCache.
This only applies to BFCacheInParent is enabled.
GetURI can succeed, but still return null. In that case, BasePrincipal::IsL10nAllowed
will pass null into NS_URIChainHasFlags, causing it to fail, which will produce three
separate warnings, and then return NS_OK. A recent change caused this function to be
call much more frequently, so this is now the top source of log spam in debug builds.
This change should not affect the behavior, aside from the lack of warnings.
Original Revision: https://phabricator.services.mozilla.com/D219065
Differential Revision: https://phabricator.services.mozilla.com/D219576
The latest Widevine DLL added a dependency for APIs provided by
shell32.dll which we did not previously allow the Widevine GMP process
to access. This patch (thanks Bob Owen!) adds it to the list of DLLs to
preload before enabling the sandbox.
The difference can be observed by using SystemInformer's peview to see
the list of imported DLLs and methods by the Widevine DLL. This allowed
us to see that shell32 was a new dependency.
Differential Revision: https://phabricator.services.mozilla.com/D219159
After updating the Widevine plugin to 4.10.2830.0, we would crash on
startup of the plugin because it attempted to use the stat syscall.
Allow uses of stat for files that we have already opened / allowed
access to in the GMP sandbox.
Differential Revision: https://phabricator.services.mozilla.com/D218855
We already landed the necessary support for CRX3 in bug 1860397. The
difference with the compontent update service is that the Widevine
archives store the plugin files in a different folder within the archive
than before.
This patch makes it so that we extract all binaries/manifest files,
flattening the archive structure in the process. This should continue to
work for our present Widevine update mechanism, as well as the Chrome
component update service in the future.
Original Revision: https://phabricator.services.mozilla.com/D216703
Differential Revision: https://phabricator.services.mozilla.com/D218843
