I'm not sure if the weird dmanip behaviour coming from the OS is new (because we have a new bug (bug 1697091) that seems like dmanip has changed what it sends us sometimes), or has always existed. But it seems like a good idea to make the code robust against this.
We can hit this assert in the following way. It seems as though dmanip decides after the first few OnContentUpdate calls if it is processing a pinch or a pan (because we can get a scale that is slightly different from 1 on the first OnContentUpdated call, but after that point never changes at all while the offset is changing fluidly) and if it decides it is a pan then it locks the scale to whatever it's last value was. So if we get a scale that is very close to 1 but not fuzzy equal to 1 on the first OnContentUpdated call we will decide that we are processing a pinch, but dmanip can then decide that it's processing a pan. Once the user lifts their finger dmanip will inform us via OnViewportStatusChanged that it is now in inertia mode, it is allowed to go into inertia for pans but not pinches because we pass DIRECTMANIPULATION_CONFIGURATION_TRANSLATION_INERTIA but not DIRECTMANIPULATION_CONFIGURATION_SCALING_INERTIA when we create dmanip here https://searchfox.org/mozilla-central/rev/87a8afd9f57ee4bc542ba0ec3f96a891042b6db7/widget/windows/DirectManipulationOwner.cpp#554 And then dmanip can go straight from inertia to running, this causes us to start a new pinch because our current scale is not fuzzy equal to 1. But also, the current scale has not changed, so it is equal to our last scale, so we have no scale change to send in the pinch start event.
An example of logging when it happens is helpful for understanding and can be found at https://bugzilla.mozilla.org/show_bug.cgi?id=1697756#c2
Differential Revision: https://phabricator.services.mozilla.com/D107994
The IDs of actions pinned to the urlbar are kept in
`PageActions._persistedActions.idsInUrlbar`. To pin all actions to the urlbar,
theoretically all we need to do is add all action IDs to this array, and things
should just work. PageActions already has a migration mechanism that could check
if Proton is enabled and add all the action IDs if it is. However, that would
mean that if Proton were subsequently disabled, or if the user downgraded to a
Firefox without Proton, they'd end up with all their actions still in the
urlbar. They could remove them one by one so it's not a big problem, but it
would be annoying.
Instead, this patch keeps two arrays of urlbar IDs. One stashes the user's
original pinned actions and PageActions never touches it as long as Proton is
enabled, and the other is the usual array that happens to have the IDs of all
the actions when Proton is enabled.
Depends on D107763
Differential Revision: https://phabricator.services.mozilla.com/D107600
We seem to have cargo-culted this in from nearby gfx code, but since we read
prefs only during the spidermonkey prefs callback this is a bit silly. Note
that the Streams cases *do* make use of off-thread uses of the mirror
variable from within Gecko.
Differential Revision: https://phabricator.services.mozilla.com/D108127
To simplify this code, turns these prefs into unlisted prefs on MIPS
platforms since the JIT support is missing there. The JitOptions will
continue to default them to false on MIPS.
Differential Revision: https://phabricator.services.mozilla.com/D108107
These prefs are unlisted in all.js / StaticPrefs and so make sure that is
obvious from the code and that their default is explicit. These probably
should just become listed prefs in the future.
Differential Revision: https://phabricator.services.mozilla.com/D108103
These prefs are unlisted (eg not in about:config) and seem to hark back to a
different era. In practice, setting the appropriate JIT threshold to 0 does
the same thing and is much clearer.
Differential Revision: https://phabricator.services.mozilla.com/D108102
The "barriers" here refered to type-barriers which no longer exist after
IonBuilder was removed so this pref is now dead. Also remove the .misc suffix
of the sibling pref.
Differential Revision: https://phabricator.services.mozilla.com/D108123
This is follow-up to Bug 1687549, which added the `maxsize` flag.
That works well, but it's hard to distinguish separate logging
sessions. This makes it a little easier.
This calls through to a slightly modified `Print`, leveraging the
concurrency correctness of that implementation. Doing so doesn't
allow great visual distinction, but it's enough.
This produces output like:
```
$ firefox --backgroundtask success --MOZ_LOG prependheader
***
[(null) 1937604: Main Thread]: I/Logger Opening log
*** You are running in background task mode. ***
...
```
and
```
$ firefox --backgroundtask success --MOZ_LOG prependheader,raw
***
Opening log
*** You are running in background task mode. ***
...
```
Differential Revision: https://phabricator.services.mozilla.com/D106224
This patch makes sure the repo can be built without `MOZ_LAUNCHER_PROCESS`.
- Compile WinTokenUtils.cpp under winlaucher regardless of `MOZ_LAUNCHER_PROCESS`
because we still need `IsAdminWithoutUac`.
- Skip TestDllBlocklist.NoOpEntryPoint GTest because the `RedirectToNoOpEntryPoint`
feature is only available with the new blocklist with the launcher process.
Differential Revision: https://phabricator.services.mozilla.com/D108142
If the "mach" file and all "*.py" files are unchanged, then the reported
exception is likely legitimate and can be reproduced on the public tree.
Differential Revision: https://phabricator.services.mozilla.com/D108262
This patch:
-Maintains consistency between the fxa and remote tabs' panels "sync now" buttons
-Removes a fluent string no longer in use
-Restores tooltip functionality
Differential Revision: https://phabricator.services.mozilla.com/D106651
* Applies it on toolbarpaletteitem for customize mode.
* Stops applying it on every child of the first toolbaritem child, since the content of toolbaritem is unpredictable (zoom-controls, reload/stop, profiler icon & dropmarker.
Differential Revision: https://phabricator.services.mozilla.com/D108258
This change unifies the different colors of splitters used within the different panels.
"Splitter" here referes to a thin (usually one pixel wide) line between different items in the UI. It does not mean borders around items.
Differential Revision: https://phabricator.services.mozilla.com/D105682
Bootstrap runs mach create-mach-environment, which may or may not
successfully install glean. When it doesn't, it's not useful to ask
whether to enable telemetry when it's not going to work.
Differential Revision: https://phabricator.services.mozilla.com/D108131
The function to detect whether the kernel has separate syscalls for
socket operations (rather than only `socketcall`) had a comment that
it's called only once, which is no longer true. So, this seems like a
good time to add a cache (but not on newer archs like `x86_64` where the
answer is constant).
This patch also removes the ifdefs on `__NR_socket`, because all archs
have it now, and our local headers will define it even if the build
host's headers don't.
Differential Revision: https://phabricator.services.mozilla.com/D105853
When setting up calls to `sendmsg` for IPC on Unix systems, we generate
`iovec`s for the entire message or until the `IOV_MAX` limit is reached,
whichever comes first. However, messages can be very large (up to 256
MiB currently), while the OS socket buffer is relatively small (8KiB on
macOS and FreeBSD, ~200KiB on Linux).
This patch detects the socket buffer size with the `SO_SNDBUF` socket
option and cuts off the `iovec` array after it's reached; it also adjusts
the Linux sandbox policy to allow reading that value in all processes.
On my test machines this increases throughput on large messages by about
2.5x on macOS (from ~0.3 to ~0.7 GB/s), but on Linux the improvement is
only about 5% (most of the running time is spent elsewhere).
Differential Revision: https://phabricator.services.mozilla.com/D105852
Currently we walk through the entire list of not-yet-written IPC buffers
when building the gathered I/O list for `sendmsg`, to determine the
total remaining length of the messages, even after reaching the OS's
limit on how many `iovec`s it will accept in one call.
This patch halts the iteration when we reach the `iovec` limit, because
we don't need the exact length; it's sufficient to know whether the
entire message was written, which is impossible in that case.
This increases throughput on large messages by about 7x on macOS (from
~0.04 to ~0.3 GB/s) and 1.7x on Linux (from ~0.3 to ~0.5 GB/s), on my
test machines. The effect is more significant on macOS because its
smaller socket buffer size (8kB vs. ~200kB) means we spend more time
setting up the syscall per unit data copied; see also the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D105851
This patch enables the following tasks on mozilla-central:
> test-macosx1014-64-qr/debug-mochitest-plain-fis-e10s
> test-macosx1014-64-shippable-qr/opt-mochitest-plain-fis-e10s
> test-windows10-64-qr/debug-mochitest-plain-fis-e10s
And the following tasks on autoland:
> test-linux1804-64-qr/opt-mochitest-plain-fis-e10s
> test-macosx1014-64-qr/debug-mochitest-plain-fis-e10s
> test-macosx1014-64-qr/opt-mochitest-plain-fis-e10s
> test-windows10-64-qr/debug-mochitest-plain-fis-e10s
> test-windows10-64-qr/opt-mochitest-plain-fis-e10s
Depends on D108251
Differential Revision: https://phabricator.services.mozilla.com/D108252
Fix a bug where camera was being omitted from accounting in cases where
camera and mic where obtained jointly with a single getUserMedia call.
The permission grace period implementation relies on more accurate
accounting of when individual active devices are deactivated, and this bug
caused an existing test to fail and permission to slip through by failing
to account for cameras needing clearing from webrtcUI.activePerms during a
session.
Also remove a few redundant lines from said test (behavior neutral).
Depends on D106043
Differential Revision: https://phabricator.services.mozilla.com/D107769
This hacks around the fact we want to use desktop relative cursor position
on Linux but not on Windows and OS X. This version of the constructor has
been removed upstream, so this will need to be fixed in a different way
as part of the libwebrtc update.
Differential Revision: https://phabricator.services.mozilla.com/D107895
