The previous traversal strategy for assigning render tasks is very
simple and works fine for normal content. However, it's possible to
create graphs with very deep levels of nesting and dependencies
that cause the pass traversal to not terminate quickly.
This patch contains two changes to fix these cases:
- Recursion in assign_render_pass will early out if a shorter
path has been found.
- Remove recursion from assign_free_pass, iterating each task once.
Differential Revision: https://phabricator.services.mozilla.com/D101541
I missed these in bug 1682405.
Additionally, after this removal, llvmorg-10-init-5191-ga84b200e604-windows-pgo.patch also becomes unused, so it is deleted too.
Differential Revision: https://phabricator.services.mozilla.com/D101633
Warp and Baseline disagree about whether a >>> b should return a double or an Int32 when allowDouble is true and the result fits in Int32. This can cause a bailout loop if the result feeds into a GuardToInt32.
Differential Revision: https://phabricator.services.mozilla.com/D101532
This MOZ_CRASH is being hit in Nightly. The numbers are still small (8 crashes from 5 installs so far) but to be safe we can downgrade it to a debug assert for now.
The only case in FinishBailoutToBaseline where we don't either update the BailoutAction or invalidate the script is if we hit BailoutKind::DuringVMCall without an exception pending. I'm not sure how that happens, and we obviously don't have any test coverage for it. Maybe something involving interrupts?
Differential Revision: https://phabricator.services.mozilla.com/D101531
This patch converts `GeckoChildProcessServices.java` into a jinja template.
We also add an overlay generated from a jinja template for `AndroidManifest.xml`
that provides the definitions for content process services.
Note that even though Gradle supports simple substitution of variables in
manifests, I opted not to use that functionality. Since we need the more
powerful template functionality that jinja provides, I felt that having multiple
ways to substitute information into the manifest would be confusing, so we're
using jinja exclusively.
Differential Revision: https://phabricator.services.mozilla.com/D82578
* We add a config option for setting the number of content services;
* We add a config option to indicate whether content services should be isolated.
This one is just a `project_flag` since it doesn't really need the ability to
be overridden; it's something whose default we would want to flip when the
time comes;
* We set a dependency so that mobile/android/base/pre-export is executed;
* We add the `gen_from_jinja.py` script which is mostly just a dumb shim that
takes the input template and the config arguments, instantiates jinja,
generates the final output, and dumps it to the output fd;
* We add the requisite `moz.build` statements to generate the manifest overlay
and the service definitions;
* We update `build.gradle` so that Gradle knows to look for the generated files
when building the apk.
Differential Revision: https://phabricator.services.mozilla.com/D82577
These are the minimum changes that we need to make to common build system code
to allow us to generate files during pre-export.
We add a `required_before_export` flag to `GeneratedFile` to indicate when a
particular file must be generated in `pre-export`. We set that flag when there
are `.jinja` input files and we're configured for a GeckoView build, otherwise
it is set to `False`.
Then the recursive `make` backend assigns any `GeneratedFile`s that have
`required_before_export` set to run in the `pre-export` tier.
Differential Revision: https://phabricator.services.mozilla.com/D82576
Dump wayland buffers as png images when MOZ_WAYLAND_DUMP_WL_BUFFERS env variable is set and also log that.
The images are stored in recent working directory unless MOZ_WAYLAND_DUMP_DIR is set.
Differential Revision: https://phabricator.services.mozilla.com/D101581
The BaseApp has been renamed to follow org.mozilla.firefox ID.
Additionally update the Docker image used to run the flatpak build.
Differential Revision: https://phabricator.services.mozilla.com/D100647
`BigInt.as{Int,Uint}N(bits, x)` with bits={32,64} are expected to be common enough
to warrant providing specialised code. For example `BigInt.asIntN(64, x + y)` can
be used to inform the compiler to perform Int64 additions.
Differential Revision: https://phabricator.services.mozilla.com/D101173
The fast path didn't handle the no-op case, which actually made the fast-path
slower for the case when no conversion is necessary.
Differential Revision: https://phabricator.services.mozilla.com/D101167
This patch is to improve the way to detect an injected dependent module for
automatic DLL blocking (bug 1659438).
In the previous version, we created a list of dependent modules in the launcher
process and shared it with other processes via the shared section. However, it
was not compatible with third-party applications who tamper the Import Table and
revert it in the injected module's DllMain (bug 1682834) because we parsed the
Import Table in the launcher process after it was reverted.
With this patch, we check the Import Table in `patched_NtMapViewOfSection`,
so we can see tampering before it's reverted. More specifically, we create
a list of dependent modules in the browser process as below.
1. The launcher process creates a section object and initializes
the kernel32.dll's functions in it.
2. The launcher process transfers a writable handle of the shared
section to the browser process.
3. In the browser process, if an injected dependent module is being
mapped by `NtMapViewOfSection`, we add its NT path to the shared
section and block it with `REDIRECT_TO_NOOP_ENTRYPOINT`.
4. The `main` function of the browser process converts the writable
handle of the shared section into a readonly handle.
5. The browser process transfers a readonly handle of the shared
section to a sandbox process.
Since automatic DLL blocking may still cause a compat issue like bug 1682304,
we activate it only in Nightly for now.
Differential Revision: https://phabricator.services.mozilla.com/D101460
To clarify the two separate SubDialog managers managed by TabDialogManager, this patch renames `_.dialogManager` to `._tabDialogManager`.
Depends on D100066
Differential Revision: https://phabricator.services.mozilla.com/D100955
The TabDialogBox will manage two separate SubDialog managers at the tab and content level. Dialogs managed at the tab level will always be on top of content ones and should always receive focus first when tab switching or refocusing the window.
Differential Revision: https://phabricator.services.mozilla.com/D100066
Steve Fink
Jeff Gilbert
Dão Gottwald
Glenn Watson
Sebastian Zartner
Simon Weckler
Sam Foster
David Major
Nils Ohlmeier [:drno]
Mihai Alexandru Michis
Christoph Kerschbaumer
Lars T Hansen
Brendan Dahl
Iain Ireland
Henrik Skupin
Aaron Klotz
Marco Bonardo
Zibi Braniecki
amy churchwell
Tim Nguyen
stransky
Bartłomiej Piotrowski
André Bargull
Toshihito Kikuchi
Julian Descottes
Micah Tigley
Paul Zuehlcke
Dorel Luca
Chris H-C
Razvan Maries