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
Note that the propagation of the target guid to places where the transform
will be applied is best-effort at the moment. In particular, the
InputAPZContext will result in the correct guid being available in places
that are called synchronously from the Recv*() functions, but not places
called asynhcronously (e.g. via DelayedFireSingleTapEvent).
To mitigate this, places where the transform is applied fall back on the
RCD-RSF if a guid is not available via InputAPZContext (added in a
subsequent patch).
The cases that this gets wrong are fairly edge casey (it requires (a) an
asynchronous codepath, (b) an event targeting a subframe, and (c) that
subframe having a "could not accept the APZ scroll position" transform),
so we just punt on them for now. If it turns out to be important to handle,
then options for doing so include (1) propagating the guid through each of
the affected asynchronous codepaths, or (2) attaching the guid to the event
itself.
Differential Revision: https://phabricator.services.mozilla.com/D68723
We will be applying and unapplying this transform in many places, and
thinking about those operations as "applying the callback transform" and
"unapplying the callback transform" is not very intuitive, especially since
applying the callback transform involves *un*applying the resolution.
Rather, going forward we will use the terminology "visual coordinates"
and "layout coordinates" and use this function to convert back and forth
between them.
ApplyCallbackTransform() is not renamed here because subsequent patches will
transition its callers to use GetVisualToLayoutTransform() and
ApplyCallbackTransform() will be removed.
Differential Revision: https://phabricator.services.mozilla.com/D68297
This function (and helper functions that wrap it) will be used extensively
throughout layout code, so keeping it in APZCCallbackHelper seems awkward.
nsLayoutUtils would also be a reasonable place but has the downside that
adding a new function to it triggers recompiling the world.
Differential Revision: https://phabricator.services.mozilla.com/D68296
The implementation was already only using the scroll id, so there is no
functional change, but this change will make it easier to new call sites
to come up with the function's inputs.
Differential Revision: https://phabricator.services.mozilla.com/D68277
This is to facilitate call sites that need to incorporate the transform into
a larger transform matrix rather than immediately applying the callback
transform to a point.
Differential Revision: https://phabricator.services.mozilla.com/D68275
Prior to this bug, it was necessary to handle non-e10s specially, because the
resolution was being unapplied at the process boundary, and in non-e10s there
was no process boundary.
The remaining patches in this bug move the resolution unapplication away from
the process boundary in all cases, making special handling for non-e10s
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D68273
Included in this patch
- Reduced the size of the raw header toggles from 16px to 12px
- The raw header toggles when the "Raw" label is clicked
- The label has changed for "Raw headers" to "Raw" as recommende by the UX designs
- Changed the Title text color of the headers accordion to make it lighter
- Disabled the input boxes when property values are selected
- Changed the color of the property values
Todo (in a different patch)
- Show learn more and copy icons on hover
- No warning icons
Differential Revision: https://phabricator.services.mozilla.com/D73230
We keep the reference of BrowsingContext across IPC call. But the
BrowsingContext may be discarded when returning from the IPC call.
This crash happens when:
A first-party window calls window.open(a 3rd-party url), which triggers
the storage access heuristic, and then the window is closed
immediatelly.
This patch fixes this issue by checking IsDiscard() when returning from
the IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D73810
To support this API, we do the following:
Additions to `GeckoSessionTestRule`:
* We add an overload to `webExtensionApiCall` that accepts a `GeckoSession`
argument. Instead of sending the message to the extension's background script,
this overload instead sends the message to the port for the session's
content script.
* We add `GeckoSessionTestRule.getSessionPid()` which uses the new
`webExtensionApiCall` overload. Moving other existing APIs over to use the
new overload is out of scope for this bug and should be done in follow-ups.
Additions to the `test-support` extension:
* We modify the content script to receive an API call message from the native
port. It then forwards the request up to the background script. By doing it
this way, the background script will receive the message along with the
WebExtension `Tab` object belonging to the sender;
* The background script's message handler merges the tab into the arguments
to the API as a `tab` property;
* The background script then calls the API and the result is returned to
the harness using the native port, just like the normal implementation;
* We add a `GetPidForTab` API for resolving top-level PIDs from a webext tab id.
Differential Revision: https://phabricator.services.mozilla.com/D73723
Mike Conley
Junior Hsu
Tarek Ziadé
Ted Campbell
Michael Cooper
Etienne Bruines
Jan-Ivar Bruaroey
Gregory Mierzwinski
Byron Campen [:bwc]
Botond Ballo
Hubert Boma Manilla
David Parks
Dimi Lee
Chanhee Cho
Sylvestre Ledru
Aaron Klotz