We use uint64_t for usages internally, but the deserializing function was using
ToInteger which can handle only 32bit integers. The problem became more visible
after increasing the group limit from 2GB to 10GB, but it was possible to
experience the problem even before that because persisted origins are not
limited by the group limit.
Differential Revision: https://phabricator.services.mozilla.com/D148480
The `_connections` map is still not quite the same between the two,
and workers auto-destroy the JSWindowActor when the last connection closes.
But this auto-destroy looks meaningless? If the map is empty _destroy won't do much...
Regarding merging or sharing code between the two actors,
I don't have a clear picture on how to do so as there is subtle differences.
It might be clearer once content process targets are using a JSProcessActor.
It would introduce a third Actor, doing probably the same things again, in a yet different way!
Differential Revision: https://phabricator.services.mozilla.com/D148477
The duplications arise from a Glean update, which has some of those as
transitive dependencies.
Upgrading Clap and others here reduces the duplication.
Differential Revision: https://phabricator.services.mozilla.com/D147659
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
This doesn't change behavior but I was going through this code and I think it
makes sense.
In general I think this code could be cleaned up a bit more, it's not clear to
me why we need the distinction between nonClientSizeMargin and borderSize, but
that's probably worth another bug.
Differential Revision: https://phabricator.services.mozilla.com/D148361
That is, when you right-click twice in the tab area (in a way such that we
close the pre-existing context menu).
Depends on D148224
Differential Revision: https://phabricator.services.mozilla.com/D148225
Add LinearFunction to TimingFunction. Because the linear function is a
variable list of linear stops, the enum is no longer Copyable.
Differential Revision: https://phabricator.services.mozilla.com/D146837
this patch fixes building firefox with
--enable-default-toolkit=cairo-gtk3-wayland-only when system mesa is build
with X11 support.
Without this patch, it only builds with mesa built without X11 support.
Differential Revision: https://phabricator.services.mozilla.com/D148347
Thanks to the exception fixed by the previous patch of this queue,
we weren't triggering `closeAllConnections`!
Calling this method was simply all wrong.
It was closing all watcher's connections intead of only the one
related to the currently destroyed target.
Doing this was breaking cases involving more than one watcher per server.
When opening RDM and a Toolbox. Closing one of the two, would destroy the other one's connection/actors/fronts.
Differential Revision: https://phabricator.services.mozilla.com/D148388
The multiprocess browser toolbox is on by default in BETA, so we
need to switch it on explicitly for the addon extensions to be listed.
Differential Revision: https://phabricator.services.mozilla.com/D148392
macOS unfair locks enforce that a lock can only be released by the thread which locked it.
On macOS 11+ this caused the fork()'d child process to raise a SIGILL signal. Confusingly enough this behavior seems to be different on macOS 10.15 and possibly interacted in odd ways with our exception handler if it was installed before fork()-ing.
Differential Revision: https://phabricator.services.mozilla.com/D148287