Added a mechanism to register and unregister the DocShells from the CorePS depending
on the state of the profiler. Registering mechanism is straightforward. During
unregistration, if profiler is not active, we remove the DocShell information
immediately. If profiler is active, we don't remove and we keep the profiler buffer
position at that moment. During another DocShell registration we Discard the
unregistered DocShells. If the profiler buffer position is greater than the position
when we captured during unregistration, we delete the DocShell since that means there
can't be any markers associated to this DocShell anymore.
MozReview-Commit-ID: IVuKQ6drvkR
Differential Revision: https://phabricator.services.mozilla.com/D4914
--HG--
extra : moz-landing-system : lando
Note: JSOP_GOSUB has a use count of 2 even though it doesn't push/pop anything.
This isn't great but was done to match the old behavior (def count of 0, pushed
2 values).
Depends on D10571
Differential Revision: https://phabricator.services.mozilla.com/D10572
--HG--
extra : moz-landing-system : lando
Unfortunately we can't test BEHAVIOR_REJECT using the AntiTracking framework,
because the AntiTracking callbacks are incompatible with it. (The tracking
callbacks expect to be able to unblock themselves, but under BEHAVIOR_REJECT,
that can't happen.)
Differential Revision: https://phabricator.services.mozilla.com/D10664
--HG--
extra : moz-landing-system : lando
This patch changes Marionette to only run the interactability test
on <input type=file> when the strictFileInteractability capability is set.
strictFileInteractability is not set by default which means
this changes WebDriver:SendElementKeys' behaviour to not run
interactability checks on <input type=file>. This aligns our
WebDriver implementation with the current behaviour in Chrome.
To make it legible what the input to interaction.sendKeysToElement
is, its API has changed to take an options dictionary instead of
three boolean arguments at the end.
Depends on D10274
Differential Revision: https://phabricator.services.mozilla.com/D10275
--HG--
extra : moz-landing-system : lando
The strictFileInteractability capability is always supported by
geckodriver.
Depends on D10273
Differential Revision: https://phabricator.services.mozilla.com/D10274
--HG--
extra : moz-landing-system : lando
The new strictFileInteractabilityTests capability takes a boolean and
can unconditionally be set to both true and false. It is permitted
to be undefined.
Depends on D10270
Differential Revision: https://phabricator.services.mozilla.com/D10271
--HG--
extra : moz-landing-system : lando
The WebDriver standard changed
in https://github.com/w3c/webdriver/pull/1325 to align with
chromedriver's behaviour of permitting interaction with hidden
<input type=file> elements.
DOM elements can be hidden, i.e. not rendered, in two ways: through
applying the "hidden" DOM attribute or by setting the "display:
none" CSS style.
Depends on D10269
Differential Revision: https://phabricator.services.mozilla.com/D10270
--HG--
extra : moz-landing-system : lando
Normally all interactability tests are centralised in interactability.py,
but the WebDriver standard recently changed to apply a special
set of interactability checks specifically for <input type=file>.
These tests ensure the special code paths are invoked for form controls.
Differential Revision: https://phabricator.services.mozilla.com/D10269
--HG--
extra : moz-landing-system : lando
As a backwards compatibility measure following bug 1388424 which
removed the ability to set the session ID, we duplicated the
capabilities dictionary in the request body.
Since this shipped through all the trees as part of Firefox 60,
we can now drop this compatibility measure.
Differential Revision: https://phabricator.services.mozilla.com/D10733
--HG--
extra : moz-landing-system : lando
Since reftest doesn't access clipboard, this test is implemented by mochitest
even if this compares with image.
Differential Revision: https://phabricator.services.mozilla.com/D10531
--HG--
extra : rebase_source : ef7bd6cc081ee5b5b821fdcef24b1c20c5315f49
When inputting any character in password field, character isn't masked
immediately since echo password is turned on Android. But when pasting text,
the text is masked immediately on Blink and Android OS.
So we should adopt this behaviour on Gecko too.
Differential Revision: https://phabricator.services.mozilla.com/D10530
--HG--
extra : rebase_source : b4bc026569e61fee697cb538719216fb258a11ae
This patch makes ImageContainer create a SharedSurfacesAnimation object
when it detects that we are using shared surfaces and are producing full
frames.
Differential Revision: https://phabricator.services.mozilla.com/D7505
This patch allows us to intercept invalidation requests for display
items, and avoid regenerating the display list for animated images which
are using SharedSurfacesAnimation.
Differential Revision: https://phabricator.services.mozilla.com/D7504
This patch embeds a SharedSurfacesAnimation object inside an
ImageContainer. This allows any consumers of the container to get the
single shared ImageKey for an animation, despite whatever surfaces may
be held inside the container at a given time.
Differential Revision: https://phabricator.services.mozilla.com/D7503
This is a non-functional change. It allows objects that build on top of
these helper classes to be exposed outside of SharedSurfacesChild in
future patches in this series.
Differential Revision: https://phabricator.services.mozilla.com/D7501
Animated images will work by changing the external image ID that an
ImageKey points to. We cannot allow the old external image to be
released and potentially unmapped until we have produced a new frame
with the new external image ID. We currently wait until the epoch has
advanced, but in the future when we don't rebuild the scene to animate
an image, the epoch will remain the same. This could cause us to hold
onto no longer used surfaces for much longer than expected. As such, in
this patch we switch to waiting for a FrameRendered notification from
WebRender, which works even if the scene rebuild was avoided.
Differential Revision: https://phabricator.services.mozilla.com/D7500
Animated images will require scheduling a composite of the frame in
addition to updating the ImageKey/external image ID bindings. It would
be good if this could be done as part of the same IPDL message.
Additionally a page may have many animated images that we update the
frame for at the same time, so these updates should be batched together.
In the event that we needed to regenerate the display list, or produce
an empty transaction, ideally we would just throw these resource updates
in with the rest of the changes. This patch allows us to do all of that
without unnecessarily burdening the caller with tracking extra state.
Differential Revision: https://phabricator.services.mozilla.com/D7499
Async animated images need a single ImageKey which can point to any
frame represented by its own external image ID. Additionally a frame
could be referenced again directly (e.g. something shows/uses the first
frame of the animated image).
Before this patch, the ownership between an ImageKey and an external
image ID for a shared surface was not clearly expressed. This resulted
in a special command to release the reference to the external image
separately from deleting the image key.
This patch makes the strong reference to an external image ID and an
ImageKey directly related. Not only does this facilitate multiple
ImageKeys owning the same surface, it also simplifies the ownership
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D7520
This also reorders the remaining members of class ReadableStream a bit.
Depends on D10435
Differential Revision: https://phabricator.services.mozilla.com/D10436
--HG--
extra : moz-landing-system : lando
In passing, change ReadableStreamControllerPullSteps to use explicit downcasts,
so it's a little more obvious what's going on.
Depends on D10430
Differential Revision: https://phabricator.services.mozilla.com/D10431
--HG--
extra : moz-landing-system : lando
This commit changes ReadableStreamReaderGenericRelease to use
UnwrapInternalSlot when accessing reader.[[closedPromise]]. Before this commit,
the code assumed that there would be a promise in the slot, not a wrapper.
I think that was actually correct, because it's impossible for the stream to
still be readable and the reader to have a [[closedPromise]] that's a wrapper.
Still, it's a bit precarious (and I'm still not 100% sure about that), so I just
changed it to unwrap.
Depends on D10374
Differential Revision: https://phabricator.services.mozilla.com/D10428
--HG--
extra : moz-landing-system : lando
