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
We do create dedicated targets for frame documents, but
in isFrameWithChildTarget, we were only checking if the
passed element was an iframe, making some area of the code
not behaving correctly (e.g. using the node picker, or
the Inspect Element context menu entry).
This patch fixes this and add a test case to make sure we
don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D140041
This cuts the time spent doing get_ct_font on macOS in half because of
various contention issues. It should also reduce overall memory usage
for large fonts because we have half as many threads loading the
fonts.
Differential Revision: https://phabricator.services.mozilla.com/D139946
`mach test` passes in a log parameter that contains a preconfigured
logger. wptrunner is already using this to configure the logger for
the test run, but because it's operating on a copy of the arguments,
we don't remove the log parameter from the kwargs we pass in
later. That causes a problem for the verify mode which assumes that
all parameters are cloneable.
Differential Revision: https://phabricator.services.mozilla.com/D140048
This removes a part of the erroneous scheme-comparison and the logging
that was implemented in those functions. The tests for that logging were
also removed.
Differential Revision: https://phabricator.services.mozilla.com/D136229
This gets done usually in BreakSink::Finish, but we don't do
line-breaking in SVG Text so we need to do this here instead.
Do you know where I could crib a test for this?
Depends on D139964
Differential Revision: https://phabricator.services.mozilla.com/D139965
With named profiles we can't expect to write prefs, or to read the port out
of the profile path. So don't do these things.
Differential Revision: https://phabricator.services.mozilla.com/D138674
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
This patch just cleans up the method code for making the changes for bug 1735608
simpler. This does not change any behavior.
Depends on D140010
Differential Revision: https://phabricator.services.mozilla.com/D140011
This patch just cleans up the method code for making the changes for bug 1735608
simpler. This does not change any behavior.
Differential Revision: https://phabricator.services.mozilla.com/D140010
