The same optimization of looking for merged linear gradients can also be
applied to radial gradients by solving the quadratic equation to check
how large a span we can process within a given merged span. This allows
us to save a bunch of table lookup and some other math in the inner loops.
Differential Revision: https://phabricator.services.mozilla.com/D105858
For linear gradients, we are currently bottlenecked by looking up a gradient
table entry, doing interpolation, and converting to pixel formats for every
sample.
We can accelerate this by instead looking for contiguous segments of gradient
within the range of entries we need to sample and then interpolating these
as a single gradient. This also enables us to convert to relevant pixel formats
only when setting up this gradient, which greatly reduces the per-pixel processing
down to essentially a shift and add.
To enable this sort of crawling of the gradient table, the output gradients have
been modified such that each entry's step value will equal an adjacent entry's
step value if and only if they are from same gradient. We can ensure this by, in
the very rare case two segments of gradient have the same step, using the equivalent
of nextafter() to imperceptibly alter the value so that the invariant is maintained.
Differential Revision: https://phabricator.services.mozilla.com/D105716
This fixes a problem where the callback just wouldn't be called for the duration
of about a minute after fast user switching. I'm hoping it'll also help with a
similar problem after screen lock and after sleep (bug 1682713).
The documentation for CVDisplayLinkStop says the following:
> In macOS 10.4 and later, the display link thread is automatically stopped if
> the user employs Fast User Switching. The display link is restarted when
> switching back to the original user.
This probably works for display links that were created before fast user
switching. However, we sometimes create a new CVDisplayLink while our user is
"in the background", and this new display link happily keeps running while we're
in the background. Then, when switching back to the original user, *that's* when
the display link is stopped. And then it eventually starts again. I'm not sure
what causes it to re-start.
Creating a CVDisplayLink while the machine is fast user switched to a different
user is probably not a well-excercised codepath. Things might work more reliably
if we keep reusing the same CVDisplayLink instance and just stop and start it
as needed. But that's a more risky change that I don't want to uplift.
Also, starting to listen for vsync while a different user is the "current" user
is probably a mistake anyway. We should find out if there's a way to suspend
compositing and drawing in that state. However, it seems that the window doesn't
enter the occluded state during this time, because in that case we would
de-activate the content docshell and not run requestAnimationFrame callbacks.
But the profiler clearly shows rAF running during the switched-away time.
I'm seeing the following display reconfiguration callbacks during fast user
switching, 2077750265 being the display link's current display:
```
[1] DisplayReconfiguration for 2077750265: BeginConfiguration
[2] DisplayReconfiguration for 1104977158: BeginConfiguration
[3] DisplayReconfiguration for 2077750265: Remove Disabled
[4] DisplayReconfiguration for 1104977158: Moved SetMain SetMode Add Enabled
[5] DisplayReconfiguration for 1104977158: BeginConfiguration
[6] DisplayReconfiguration for 2077750265: BeginConfiguration
[7] DisplayReconfiguration for 1104977158: Remove Disabled DesktopShapeChanged
[8] DisplayReconfiguration for 2077750265: Moved SetMain SetMode Add Enabled DesktopShapeChanged
```
With this patch, we restart the display link at notification 4 and 8.
In the future, we should switch to per-monitor (or per-window) vsync rather than
global vsync, and clean this whole situation up a little.
Differential Revision: https://phabricator.services.mozilla.com/D105868
Actually, before starting composition, we always remove current selected
text. So it causes that input event is fired by this operation. This is
different of Blink.
`TextEventDispatcher` can set composition string using selected text when
starting composition. So we can reduce this input event.
Also, I mistake bug 1499076 fix. By this fix, we always fires input event
when having selected text even if it is unnecessary. This changeset has
this fix too.
Differential Revision: https://phabricator.services.mozilla.com/D105464
This reduces the required swipe distance, but increases how much velocity is
needed to fling the page over the threshold.
On the touchpad, the result feels more similar to Safari now, in my testing.
With the magic mouse, it's still really easy to accidentally trigger a swipe
with a horizontal fling; it seems easier to accumulate a lot of velocity quickly
with the magic mouse.
Differential Revision: https://phabricator.services.mozilla.com/D105873
This reduces risk while we gather an inventory of exceptions that are outside
our control and which we want to ignore.
We still log all (non-ignored) exceptions in Beta/Release builds, we just don't
crash for them. So if something else later causes a crash, we will still see the
information in crash reports.
Depends on D105871
Differential Revision: https://phabricator.services.mozilla.com/D105872
nss and necko may be out of sync about 0RTT state because IsAlive drives the handshake, but nsHttpConnection is not informed about the handshake progress.
Differential Revision: https://phabricator.services.mozilla.com/D105842
Note that this only happens for chrome: documents that have been
invasively styled by userChrome.css sheets. Content documents
are never intrinsically sized, and our own chrome: sheets that
use intrinsic sizing never set 'display:none' on the :root as
far as I know. I think this is an argument for removing support
for userChrome.css.
Differential Revision: https://phabricator.services.mozilla.com/D104715
In some cases, a content process may think they should be able to make a change
to a synced field, but in the meantime something in the parent process has
changed and the change can no longer be applied. This was the cause of a number
of issues around the in-flight process ID, and can cause issues such as crashes
if the CanSet method was made too strict.
This patch introduces a new possible return type from `CanSet` which allows
requesting a `Revert`. A reverted field change will either be cancelled at the
source (if the CanSet fails in the setting process), or will be cancelled by
sending a new transaction back to the source process reverting the change to
ensure consistency.
In addition, some additional logging is added which made it easier to locate the
underlying bug and verify the correctness of the change.
The current primary use-case for this new feature is the CurrentInnerWindowId
field which can be updated by the previous process' docshell after the parent
process has already performed a switch to a new process. This can lead to the
current WindowContext being inaccurate for a BrowsingContext in some edge cases
as we allow the flawed set due the in-flight process ID matching.
This patch changes the logic to no longer check the in-flight process ID, and
instead revert any changes to the CurrentInnerWindowId field coming from a
process which is not currently active in the BrowsingContext.
No tests were added as it is very timing-sensitive, and difficult to create the
specific scenario, however without these changes my patch for bug 1663757
consistently causes geckoview-junit crashes due to currentWindowGlobal being
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D105553
Right now the resizer inside a random <div style="overflow: hidden"> is
the themed one, and that seems unintended.
I'm not sure how to best test this since resizers are sized to a
scrollbar width, so I can't just position an <img src=resizer.svg>.
I noticed this while looking at bug 1689253.
Differential Revision: https://phabricator.services.mozilla.com/D103304
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
This is a collaboration between clang-tidy and clang-format.
clang-tidy uses compiled code paths, so this patch is linux specific.
Differential Revision: https://phabricator.services.mozilla.com/D105669
* We add new options to the Android variant of `mach run`:
* `--debug`: enables running with a debugger;
* `--debugger`: Allows the user to override the default debugger (`lldb`).
The provided argument must still be `lldb` compatible; this
is for enabling the ability to specify some kind of wrapper
script or other debugger front-end, if desired;
* `--debugger-args`: Additional arguments to pass to the debugger's command line;
* `--no-attach`: Runs the app and prepares the device for debugging, but does
not actually attach any debuggers. The required ports are
printed to the log, and then `mach` exits, thus allowing for
the user to manually connect.
* `--use-existing-process`: This allows the user to attach to an existing
process, instead of killing existing process(es)
and starting from scratch. This is useful for
users who want to attach to an existing process
that is already in a desired state.
When debugging is enabled:
BEFORE the app starts:
* `verify_android_device` will install `lldb-server` if necessary;
* We run `am set-debug-app -w --persistent` to ensure that the app is set as the
device's debug app. Since we pass `-w`, when Android starts the target app, it
will wait for `jdb` to attach before proceeding.
AFTER the app starts:
* We start `lldb-server` and obtain the name of its socket file;
* We obtain the pid of the parent process. Alternatively, if
`--use-existing-process` was specified and there are already extant child
processes, we prompt the user to choose which process to which they would
initially like to attach.
* We forward a local TCP port for `jdb` debugging.
* We run `jdb` in the background to connect to the process and then quit.
This is solely for the purpose of dismissing Android's "waiting for debugger"
dialog.
* In the foreground, we run `lldb`, specifying a set of initial commands that
are required to for symbol resolution and to automatically connect to the
target pid.
Why `lldb`? I chose it for consistency with Android Studio. Somebody else is
welcome to implement `gdb` support if they wish. :-)
Differential Revision: https://phabricator.services.mozilla.com/D94384
In `verify_android_device`, when `debugger` is true, we setup `lldb-server`. We
also add a new method, `run_lldb_server`, for actually starting `lldb-server`.
Both cases call into a new function, `_setup_or_run_lldb_server`.
For setup functionality, this function copies `lldb-server` to the device and
then sets up its perms within the target app's data directory.
For run functionality, this function sets some environment variables and
(re)creates directories and log files as needed. Finally it starts the server
and returns to the caller the absolute path to the socket file on the device.
The client provides that path to `lldb` in order to connect to the server.
Both cases use `ADBDevice.batch_execute` to run several commands. The
`LLDB_SERVER_INSTALL_COMMANDS_SCRIPT` and `LLDB_SERVER_START_COMMAND_SCRIPT`
commands are intended to produce the same result as the `start_lldb_server.sh`
script that is provided by Android SDK.
Differential Revision: https://phabricator.services.mozilla.com/D94383
- We make `pidof` public and we change it to guarantee that its resulting list
of pids consists of integers.
- We update `forward` and its dependencies to return the value of the port
that was assigned by `adb` so that clients may learn which port to use when
forwarding from `'tcp:0'`
Differential Revision: https://phabricator.services.mozilla.com/D94381
We want to find the full path to the correct `lldb-server` in the NDK.
We reference this variable in a later patch when preparing the device for
debugging.
Differential Revision: https://phabricator.services.mozilla.com/D94380
NDK 21 includes `lldb-server`, which we need in order to support
`./mach run --debug` with `lldb`.
The Android SDK manager no longer includes a standalone `lldb` package; perhaps
it was deprecated? Anyway, this appears to currently be the best way to get
`lldb-server` into a location that is easy to find during build configuration.
Differential Revision: https://phabricator.services.mozilla.com/D94379
Lee Salzman
Markus Stange
Daisuke Akatsuka
Hiroyuki Ikezoe
Mark Banner
Makoto Kato
Dragana Damjanovic
championshuttler
stransky
Butkovits Atila
Mats Palmgren
Nika Layzell
Kate Hudson
Kirk Steuber
Emilio Cobos Álvarez
Timothy Nikkel
Eitan Isaacson
Aaron Klotz
Emma Malysz
Ting-Yu Lin
Kris Wright
Haik Aftandilian
Jonathan Kew
Michael Cooper
MuraliAchanti
Jan Varga
Noemi Erli
Csoregi Natalia