MozillaBuild 3.4's kernel name was `MINGW32_NT-6.2`, but the new
MozillaBuild's kernel name looks like `MSYS_NT-10.0-19044`.
Update existing first-party detection code to properly handle the modern
MSYS "kernel name" format.
Differential Revision: https://phabricator.services.mozilla.com/D140096
On Android, we must dispatch UiCompositorController::Destroy to run on
the UI thread synchronously. We were using NS_DISPATCH_SYNC to do so,
but that works by starting a nested event loop that continues to
execute tasks on the thread we have dispatched from. This means that
we can start to execute a task which calls
nsBaseWidget::CreateCompositor whilst we are midway through
nsBaseWidget::DestroyCompositor. As well as generally seeming like a
terrible idea, this also causes an assertion failure in some tests.
To avoid this use SynchronousTask rather than NS_DISPATCH_SYNC, as it
actually blocks synchronously. Additionally, do the same thing for
APZInputBridgeChild::Destroy, as it is called from the same location
and poses the same risk.
Ideally we wouldn't have to call UiCompositorControllerChild::Destroy
synchronously at all, but it was added in bug 1392705 to fix severe
crashes. It might be a good idea to re-evaluate whether it is still
required at some point in the future.
Differential Revision: https://phabricator.services.mozilla.com/D140084
Before, clang tools would only be bootstrapped if they didn't exist.
Now, bootstrapping also occurs if the version doesn't meet requirements.
Differential Revision: https://phabricator.services.mozilla.com/D137331
There's no current use for setting `JS_BINARY` in `packager.mk`, so
remove it while we're here. I elected to make it easy to add new file
types to minify rather than to make it easy to specify `JS_BINARY`,
since the latter mechanism is strictly more general and could be used
in future for things other than minification.
Differential Revision: https://phabricator.services.mozilla.com/D138364
On Android, we must dispatch UiCompositorController::Destroy to run on
the UI thread synchronously. We were using NS_DISPATCH_SYNC to do so,
but that works by starting a nested event loop that continues to
execute tasks on the thread we have dispatched from. This means that
we can start to execute a task which calls
nsBaseWidget::CreateCompositor whilst we are midway through
nsBaseWidget::DestroyCompositor. As well as generally seeming like a
terrible idea, this also causes an assertion failure in some tests.
To avoid this use SynchronousTask rather than NS_DISPATCH_SYNC, as it
actually blocks synchronously. Additionally, do the same thing for
APZInputBridgeChild::Destroy, as it is called from the same location
and poses the same risk.
Ideally we wouldn't have to call UiCompositorControllerChild::Destroy
synchronously at all, but it was added in bug 1392705 to fix severe
crashes. It might be a good idea to re-evaluate whether it is still
required at some point in the future.
Differential Revision: https://phabricator.services.mozilla.com/D140084
We noticed a cold_view_nav_start regression on Fenix from enabling the
GPU process, and profiles showed time spent synchronously waiting for
the GPU process to launch. This occured because the compositor was
being created in nsWindow::Create, and as it requires the GPU process
to be running it had to block until launch completed. The process is
launched when the gfxPlatform is first initialized, but that was only
occuring immediately prior to creating the compositor, which did not
give it enough time to complete asynchronously.
This patch makes it so that we initialize the gfxPlatform slightly
earlier, and importantly delay creating the compositor until it is
actually required. This gives the process enough time to launch
asynchronously meaning we do not have to block.
We started deliberately creating the compositor early on Android
because of bug 1453501, to avoid a race condition where the compositor
didn't exist when RemoteLayerTreeOwner::Initialize was called, causing
us to use a basic layer manager. However, since bug 1741156 landed we
now create the compositor on-demand, meaning this is no longer a
possibility.
Delaying compositor creation can, however, uncover another race
condition. If the UICompositorControllerChild is opened on the UI
thread before the main thread is able to set its pointer to the
widget, then the java GeckoSession will never be notified that the
compositor has been opened, and composition will never be
resumed. This patch fixes this issue by setting the
UiCompositorControllerChild's widget pointer in its constructor rather
than immediately afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D139842
With the later patch in this series to delay initializing the
compositor, we started crashing in ScreenshotTest#giantScreenshot due
to webrender's window size sanity check.
This check panics early if we attempt to render an area larger than
webrender can handle (rather than panicing internally in
webrender). However, this test deliberately creates a 999999x999999
sized window, to ensure that attempting to allocate a bitmap this size
for a screenshot results in an out of memory exception.
Previously this test only succeeded because we created the compositor
early with a default size of 0x0, whereas now we create it after the
widget has its very large size. Additionally, the test completes
before we have a chance to render anything, otherwise it would indeed
have crashed.
To ensure users do not hit the panic in the wild, in bug 1653649 we
added the necessary limit to the default widget size constraints,
ensuring we never create widgets that are too large. On Android,
however, we do not use the size constraints, so this had no effect.
This patch starts applying size constraints to android widgets,
meaning we do not attempt to render too large an area, and webrender
does not panic. The test still attempts to allocate a large bitmap,
and therefore still throws an out of memory exception and passes.
Differential Revision: https://phabricator.services.mozilla.com/D140050
The testcase includes a 1-second pause after the onload event fires, because the test font
includes PNG bitmaps which are asynchronously decoded. This is in theory unreliable,
but for these small images it should be plenty of time (even without any delay, the test
fails only very intermittently) -- if we're failing to decode the images even with the
1-second delay, something is probably truly broken.
(The file svg-bitmap.ttx file is not actually required to run the test, but is the source
for the svg-bitmap.ttf font file, constructed by inserting base64-encoded PNG images
into a minimal font framework.)
Differential Revision: https://phabricator.services.mozilla.com/D140057
This patch ended up adding some complexity to about:welcome, as the
language switching needs to eagerly perform fallible asynchronous
actions. Specifically it needs to get the list of addons and
pre-emptively install the langpack, which can take time, and can fail.
This necessitated building a custom React components and custom hooks to
be able to deal with these requirements.
The following command will allow for the testing of this feature.
./mach run \
--temp-profile \
--setpref "extensions.getAddons.langpacks.url=https://mock-amo-language-tools.glitch.me/?app=firefox&type=language&appversion=%VERSION%" \
--setpref "intl.multilingual.aboutWelcome.languageMismatchEnabled=true" \
--setpref "intl.multilingual.aboutWelcome.systemLocaleOverride=es-ES" `#(optional)` \
-- --new-tab about:welcome
Differential Revision: https://phabricator.services.mozilla.com/D138831
* Restructure "Using third-party Python packages" page to focus on the
"Mach commands"/"adding a Python package" use case since that's why
most people will be looking at these docs.
* Document the `<site>_virtualenv_packages.txt` behaviour and how it
relates to a Mach command's definition.
* Simplify the information around using a non-PyPI index to reference
the RelEng docs directly. It's a shame that the existing docs don't
explain how to identify tasks that need to use the internal mirror,
because I'm not sure either. There's existing cases of ad-hoc `pip`
installs //not// using the mirror, but the pattern isn't clear to me.
* Remove the "specify hashes" information, since the centralized
solution (will) automatically manage this internally.
* Arguably, it's still beneficial instructions for ad-hoc
`pip install` usages, but those are frowned upon today anyways - use
the centralized solution!
Differential Revision: https://phabricator.services.mozilla.com/D138931
