ContentTask tasks have a different lifetime than SpecialPowers tasks, with the
former being tied to the lifetime of a message manager and the latter tied to
the lifetime of a window global. That means that existing ContentTask callers
which expect to be able to register load listeners before the creation of a
window global, or which expect to persist after a page has navigated, won't
work as SpecialPowers tasks.
Since those sorts of tasks are not really resilient in the face of Fission,
they should really be written to work differently, but this patch mostly just
reverts them to using ContentTask for the time being.
Differential Revision: https://phabricator.services.mozilla.com/D53744
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This patch does several related things:
1) Updates the test helper functions in ui.js to make them sensible
for both the old and new RDM UI.
2) Updates the test helper function addRDMTask to return the correct
"browser" values for both RDM UIs. Old RDM UI tests that want to
spawn a content task should now use ui.getViewportBrowser() for that,
and only use the browser value for getting/setting of zoom and any
other methods that take browsers as arguments.
3) Updates the test helper function promiseRDM to make it wait on
the correct event.
4) Updates a non-zoom test that uses addRDMTask to use the new
browser value correctly.
5) Updates a zoom test to use the addRDMTask function, and therefore
run the test using the new RDM UI. This test exercises the issue
that is the focus of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D56510
--HG--
extra : moz-landing-system : lando
The firing of the "ZoomComplete" event is no longer necessary, now
that ZoomParent fires a "PostFullZoomChange" event, which serves a
similar purpose. The next part of the patch listens for that event.
Differential Revision: https://phabricator.services.mozilla.com/D56509
--HG--
extra : moz-landing-system : lando
Because the new RDM UI does not retain the width and height of the
device, this patch extracts those values from the prefs which are
updated in the viewports reducer. There probably should be a more
resilient way to maintain those values.
Differential Revision: https://phabricator.services.mozilla.com/D54379
--HG--
extra : moz-landing-system : lando
Not everything that blocks requests sets a reason other than BLOCKING_REASON_NONE.
Differential Revision: https://phabricator.services.mozilla.com/D57072
--HG--
extra : moz-landing-system : lando
This revision introduces a check for whether or not grid-item properties have an affect on an “absolutely-positioned” grid element. It’s important to note this grid element is not necessarily a grid item, it just needs to be contained within a grid container that generates its containing block. The general algorithm for this is to first check whether or not the element is either `position: fixed` or `position: absolute` then find an ancestor grid element that generates its containing block.
To help DevTools identify such an element, InspectorUtils provides an API called `containingBlockOf` that returns the absolutely-positioned element’s containing block. If the element’s containing block is the viewport, then this method returns null. For now, `containingBlockOf` is designed for absolute/fixed positioned elements. So it’s important to be aware that trying to use it for other purposes might return unexpected results.
This revision also adds/updates tests that check whether or not grid-item properties are active on a grid element.
Differential Revision: https://phabricator.services.mozilla.com/D55400
--HG--
extra : moz-landing-system : lando
Since `parent_intercept` requires to be set from the beginning, either we disable the test when it's not the case, or we force the pref to be flipped for this test… I chose the former, but happy to do the latter if it's preferable.
Differential Revision: https://phabricator.services.mozilla.com/D56762
--HG--
extra : moz-landing-system : lando
Depends on D56330
Renaming the "tab" getter to "localTab" will make it easier to refactor later.
Differential Revision: https://phabricator.services.mozilla.com/D56331
--HG--
extra : moz-landing-system : lando
Depends on D56327. Not reason to make target-mixin more complex for this workaround which already has access to the tab object.
Differential Revision: https://phabricator.services.mozilla.com/D56330
--HG--
extra : moz-landing-system : lando
It is not clear why tab unload should be listened to on the client, and only destroy the target front.
Tentatively removing to simplify the local tab target.
Differential Revision: https://phabricator.services.mozilla.com/D56327
--HG--
extra : moz-landing-system : lando
This will be helpful when consumers don't want to
keep the target around.
A test is added to ensure this work as expected (and
was failing if the returned function does not call
EventEmitter.off).
Differential Revision: https://phabricator.services.mozilla.com/D56685
--HG--
extra : moz-landing-system : lando
All the rejections were called with 2 arguments, when reject only
cares about the first one.
This patch makes all the reject called with the actual DOMException,
and adds console.error before all those rejections.
Differential Revision: https://phabricator.services.mozilla.com/D56859
--HG--
extra : moz-landing-system : lando
Some tests are failing on Linux ccov when adding
item to the webconsole history. I suspect it could
be because some expression have emojis, but I'm
not sure.
Catching the rejection will at least not make the
test fail.
Differential Revision: https://phabricator.services.mozilla.com/D56744
--HG--
extra : moz-landing-system : lando
Request a ChangesFront for each target as soon as is becomes available.
The on-demand approach in D54725 is abandoned because it introduces a client-server round trip on _every_ CSS mutation operation due to the need to ensure the ChangesActor is instantiated. By awaiting `changesFront.setup()` on every mutation, needless slowdown is introduced after the actor becomes available. Furthermore, the approach in D54725 spreads the knowledge about the ChangesFront in too many places in the codebase, something that will only get worse over time as the ChangesActor gains capabilities to track CSS changes from other sources or supports tracking DOM changes.
Differential Revision: https://phabricator.services.mozilla.com/D55945
--HG--
extra : moz-landing-system : lando
