The spatial node index and clip chain id are no longer directly
related concepts, since they now exist in different representations
(the spatial tree and clip store).
Removing the grouping of these during scene building simplifies
some work in progress to refactor how WR internally represents
clips, in order to allow future optimization work.
Differential Revision: https://phabricator.services.mozilla.com/D73187
Installed privileged addons in GeckoView sometimes need to send messages from
content scripts. Today we use the in-memory flag `ALLOW_CONTENT_MESSAGING` to
allow a specific built-in addon to send messages from content scripts, but for
installed extensions we need a way to persist this flag.
To do this, this patch introduces a new privileged permission
`nativeMessagingFromContent`, when this permission is present in the manifest,
the addon will be allowed to send native messages from content scripts (note:
the addon will also need `nativeMessaging` as usual).
When the permission is not present, any attempt to send a native message from a
content script will result in an error, similarly to what happens before this
patch.
Differential Revision: https://phabricator.services.mozilla.com/D72976
Sometimes extensions call tabs.create immediately on startup. In that case the
delegate may not be attached yet. To avoid losing these messages we store them
until a delegate is attached.
This also includes a refactoring to unify behavior for delegates. Eventually I
want to factor out delegates similarly to what happens in GeckoSession today.
Differential Revision: https://phabricator.services.mozilla.com/D72975
We use this to send a default action to the embedder, but if no one is
listening there's no point, and it causes problems in tests because sometimes
the delegate is attached / reattached too quickly and the second delegate will
end up getting two messages by mistake.
Differential Revision: https://phabricator.services.mozilla.com/D72974
I apologize for mixing multiple types of changes in this patch. The mix is probably harder to review than necessary.
Because of the way these .cpp files are listed in mozglue/baseprofiler/moz.build,
they are only built when MOZ_GECKO_PROFILER is set. So the #ifdef MOZ_GECKO_PROFILER
wrapper is now unnecessary.
Removing this wrapper has many knock-on effects on other lines in these files
due to preprocessor line indentation.
As I was removing the #ifdefs, I was reordering includes as well, to follow the
include order laid out on https://google.github.io/styleguide/cppguide.html#Names_and_Order_of_Includes ;
namely, system headers should go before "your project's" .h files.
I also removed the BaseProfiler.h include from some files but not from all.
In the past, the BaseProfiler.h include served the purpose of picking up the
MOZ_BASE_PROFILER #define, and it's no longer needed for that reason.
There are probably lots of now-unnecessary BaseProfiler.h includes left.
Differential Revision: https://phabricator.services.mozilla.com/D73527
Chrome and Safari ignore pinch zooming while a select dropdown is open.
The other option is to close the dropdown, which is what we already do if you two finger scroll on the touchpad. Chrome and Safari also ignoring two finger scrolling while a select dropdown is open.
Differential Revision: https://phabricator.services.mozilla.com/D73539
We need to set up the notebook deps.
The train of patch re-activated some
tests that required the dependencies used
by the notebook, which were not added in the
path.
Differential Revision: https://phabricator.services.mozilla.com/D73936
With JSFunction allocations deferred until after at least parsing, we have
the correct nargs on the FunctionBox by the time we allocate that function.
This lets use remove a number of `synchronizeArgCount` calls.
Standalone functions still need to be updated after parsing completes because
the function is an input.
BinAST allocations aren't deferred yet, so leave those calls alone.
Differential Revision: https://phabricator.services.mozilla.com/D73880
The "this" state is not persistent across spawn-calls, using "this" in
"function" also does not make a whole lot of sense.
In order to persist the Promise across spawn-calls, the value is stored
in "content" instead.
Since one cannot reliably return an Event from SpecialPowers.spawn (due
to serialization issues), we are awaiting them instead of returning.
Differential Revision: https://phabricator.services.mozilla.com/D73913
This patch reduces the redundancy in the mozproxy perfherder data names. It removes the `replay` suffix since it's already clear it's related to replay/not-replayed. The subtest names have the `mozproxy-replay` prefix removed through the addition of a new way of specifying supporting measurement values. Instead of only being able to submit the values with a `{measurement: values}` format, we can now submit it as `{measurement: {values: [], <SUBTEST-OPTIONS>}}`. The subtest options include perfherder-specific options, and some settings that change how the names are built. Furthermore, the full supporting data dictionary also includes two new fields: `summarize-values`, and `suffix-type`. The former dictates whether or not a summary value is produced, and the latter determines if the name should be suffixed with the data type.
Differential Revision: https://phabricator.services.mozilla.com/D72695
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
This allows headers which nsLayoutUtils.h includes to use these types without
creating a circular dependency.
As part of this change, the types are also moved into namespace mozilla.
Differential Revision: https://phabricator.services.mozilla.com/D71704
This is the anti-climactic end of the patch series.
I set out in this bug to get this test case to pass with apz.allow_zooming.
It took all these changes to do so without regressing other tests.
Differential Revision: https://phabricator.services.mozilla.com/D69644
This test is failing due to the rounding error described in bug 1627365.
As this is a web platform test, it seems inappropriate to modify the
test itself upstream to avoid a Firefox-specific rounding error.
Differential Revision: https://phabricator.services.mozilla.com/D69641
The idea here is:
* The incoming point comes from WidgetEvent::mRefPoint which is in
visual coordinates.
* Depending on the value of the target RelativeTo parameter, we
may need to convert this to layout coordinates.
* In the fast-path, we do a direct check on the viewport type
and apply the visual-to-layout transform if appropriate.
* In the slow path, we rely on TransformRootPointToFrame() (which
calls GetTransformToAncestor()) to include the visual-to-layout
transform if appropriate, by correctly passing in
ViewportType::Visual as the starting point.
* To make sure we get into TransformRootPointToFrame(), we
set transformFound if we'll be crossing a zoomed content root.
Differential Revision: https://phabricator.services.mozilla.com/D68921
This is the "core" change of the patch series, which causes most
existing layout codepaths to correctly factor in the visual to
layout transform (or its inverse), as long as the callers correctly
propagate it in the correct ViewportType.
Differential Revision: https://phabricator.services.mozilla.com/D68920
This "upgrades" various nsLayoutUtils functions which take as inputs
a set of coordinates and a frame that the coordinates are relative to,
to accept a RelativeTo object instead of a frame.
Most of the patch is just dumb propagation, but the few places where
we use an explicit ViewportType::Visual are important. There are
probably a few other places I've overlooked, but this seems to cover
the important ones that come up commonly.
There are undoubtedly other functions into which we can propagate
RelativeTo, in this patch I've propagated it as far as necessary
for my needs in this bug (mainly GetTransformToAncestor() and
GetEventCoordinatesRelativeTo()).
Differential Revision: https://phabricator.services.mozilla.com/D68919
This is already the case for real input events since that's how they
arrive from APZ, and we are no longer changing the coordinates at
the process boundary.
For synthesized events, a future patch will add layout-to-visual
converions to code that sets mRefPoint as appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D68917
