This increases the stack size used for task controller threads to the size
previously used for JS helper threads. Some parsing use cases can use a lot of
stack.
Differential Revision: https://phabricator.services.mozilla.com/D118184
This adds plumbing to make the JS engine set the stack quota based on the
actual stack size for external thread pool threads (and internal thread pool
ones).
The quota is calculated as 90% of the size, which is currently hardcoded into
the constants.
Differential Revision: https://phabricator.services.mozilla.com/D118183
Currently, as part of initialization of xul.dll on Windows we dynamically
load some DPI-related functions on Windows 10. Those functions cannot be used
with Win32k lockdown, and thus there is no point to loading them.
Differential Revision: https://phabricator.services.mozilla.com/D116629
Currently, we set DPI awareness in the manifest files for firefox.exe.
Unfortunately, that causes DPI-related Win32k calls when user32.dll
is loaded.
This changes things to wait until we are sure we're not running in a
Win32k Lockdown Content Process before we attempt to initialize DPI scaling.
Differential Revision: https://phabricator.services.mozilla.com/D116433
When session history (and bfcache) run in the parent process, things happening there are less asynchronous vs. having session history
in the child process.
The fix is such that if the disabled state doesn't change, then the test will just time out.
Differential Revision: https://phabricator.services.mozilla.com/D117891
This particular race is a tricky one - there's no perfect solution to protecting the timer thread from being called in `cancel` while being dereferenced. This ensures that we won't run into that problem by locking all of our TimerThread calls behind a mutex inside a wrapper class. Then we hold onto the wrapper class until after we shutdown `nsThreadManager`, in which case no background thread pools should be active anymore to call `nsTimerImpl::Cancel`.
For reference, the worst-case scenario happens when another thread dereferences `gThread` [between these two calls](https://searchfox.org/mozilla-central/rev/98a9257ca2847fad9a19631ac76199474516b31e/xpcom/threads/nsTimerImpl.cpp#402-403), in which case we will get stuck on a dereferenced mutex. By putting the check and the actual call into `gThread` behind a mutex maybe we can prevent this issue.
Differential Revision: https://phabricator.services.mozilla.com/D115453
We kept this class around so that we could toggle back and forth between the
Photon-era footer button style, and the Proton-era menuitem style for footer
buttons.
Now that v89 has shipped, we can remove that class and switch the markup and
styling over completely to the Proton styling.
Differential Revision: https://phabricator.services.mozilla.com/D117553
Over time the render target debug view has accidentally started
displaying other texture cache textures too, and then not actually
showing render targets. This makes it show only render target textures
again, as intended.
Differential Revision: https://phabricator.services.mozilla.com/D118187
The `mozbase` modules were being unconditionally added to the
`sys.path` regardless of the Mach command being run, so there isn't
much value keeping them in a separate file. Besides, all other
source module paths are described in `common_virtualenv_packages`,
why is `mozbase` special?
In the future, we're going to want to make improvements here (such as:
there's a difference between informing mach of first-party code
versus defining which third_party vendored packages should be in scope,
and that workflow difference should be represented in-code).
It's useful to peel out the existing, less useful abstraction before
we can build a stronger one.
Differential Revision: https://phabricator.services.mozilla.com/D117711
Having separate `<name>.pth` files in the virtual environments
isn't providing an advantage. We can simplify configuration
by putting all `pth` adjustments into a single file: `mach.pth`.
Differential Revision: https://phabricator.services.mozilla.com/D117710
This has two benefits:
1. `handle_package()` becomes more clear - rather than referring to
`action` and `package` with array index numbers, we now give
them real names. The benefit here is also shown in `up_to_date()`.
2. This makes the top-level parser for `packages()` less opinionated
about sub-formats: if an action has a nested structure, it should
have the flexibility to define what it looks like.
Differential Revision: https://phabricator.services.mozilla.com/D117708
- expand the API surface that is stubbed out more completely to account for sites relying on deprecated or more obscure functionality.
- have the shim perform basic content placement as some sites expect GPT to do.
Differential Revision: https://phabricator.services.mozilla.com/D118098
This stops creating allocation sites for IC stubs when running in the baseline
interpreter. When a script is compiled in baseline proper this scans the IC
chain for ops that could potentially reference allocation sites, and allocates
them where necessary.
This should result in fewer sites being created and less overhead for code that
doesn't reach baseline.
Differential Revision: https://phabricator.services.mozilla.com/D117920
Instead of defining (slimmed-down) constructors on the instrinsics holder,
simply use the JSOp::BuiltinObject mechanism (which uses ProtoKey slots on the
GlobalObject). This reduces the initialization requirements on the self-hosted
global which simplifies removing it later. Using `BuiltinObject` instead of
`GetIntrinsic` loses BaselineInterpreter support but the cases here are
uncommon.
Differential Revision: https://phabricator.services.mozilla.com/D118106
Instead of relying on builtin bindings for well-known symbols, use the
BytecodeEmitter to map `GetBuiltinSymbol` to `JSOp::Symbol`. The old code relies
on `GetIntrinsic` to clone by matching well-known symbol code, while the new
system directly uses `JSOp::Symbol` with the appropriate symbol-code.
Differential Revision: https://phabricator.services.mozilla.com/D118105
After some testing in `try` and locally, the manual
`PYTHONEXECUTABLE` definitions shouldn't be needed
anymore.
There's been some work on Brew's
Python to improve its `sitecustomize` behaviour.
The most likely improvement is:
https://github.com/Homebrew/homebrew-core/pull/65297
However, I'm not fully confident in this change.
If it fails, it's more likely to affect developers
than CI. I think it's worth attempting a landing,
because if the variable is indeed obsolete, then
deleting it will avoid some spicy "action-at-a-
distance" behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D117452
This patch forces perfdocs to produce unix line endings rather than os-specific line endings. This fixes an issue where generating the docs on windows causes all the docs to change because of the line endings.
Differential Revision: https://phabricator.services.mozilla.com/D117919
Instead of drawing updates into the correct spot in the destination
DataSourceSurface we just use it as scratch space and always
draw in the top-left with stride = bpp*width.
We add a dstOffset to the upload functions to support using
a subsurface.
Differential Revision: https://phabricator.services.mozilla.com/D116501
In order to fully comply with the spec and work on all compositors.
This is heavily inspired by `NativeLayerCA`:
- Buffer are managed within a pool, similar to `SurfacePool`. This
makes sure there's always a buffer available, even if the compositor
holds buffers for longer than usually expected. One difference is
that buffers are not shared between windows though, reducing
complexity.
- Partial damage is handled by blitting from the previous buffer,
likely currently held by the Wayland compositor. While the spec is
not completely clear whether this is legal, it strongly suggests it
is - and other Wayland developers suggested it should be.
This is almost identical to `NativeLayerCA::HandlePartialUpdate`,
with a small optimization for the common case of double buffering,
in witch case use a "damage history", inspired by the EGL partial
damage support. As single or double buffering are by far the most
common cases for shm-buffers, we limit this to double buffering to
avoid complexity.
Changes compared to the existing `WindowSurfaceWayland` include:
- reduced complexity:
- less code
- no extra frame callbacks, avoiding extra steps like D117911
- no compositor specific modes - this solution should always produce
fully correct output with minimal overhead.
Note: a previous version of this patch only worked for SW-WR but not
Basic and thus did not replace `WindowSurfaceWayland`. Now this patch
supports both, making it possible to fully replace `WindowSurfaceWayland`
Differential Revision: https://phabricator.services.mozilla.com/D118025
Brindusan Cristian
Jon Coppeard
Andrei Oprea
Silke Hofmann
Joel Maher
Julian Descottes
Chris Martin
Mike Conley
Olli Pettay
Kris Wright
Alexandre Poirot
Ava Katushka ava8katushka
Bernard Igiri
Csoregi Natalia
Ryan VanderMeulen
prathikshaprasadsuman
Jamie Nicol
Mitchell Hentges
Thomas Wisniewski
Mark Banner
Kershaw Chang
Ted Campbell
Gregory Mierzwinski
Jeff Muizelaar
Robert Mader
Gabriele Svelto
Alexis Beingessner
Nicolas Silva