1. Adding a new method void closePayment(in AString requestId) in
nsIPaymentUIService.idl
2. Implementing the closePayment method in paymentUIService.js.
3. Calling closePayment of paymentUIService.js in
PaymentRequestService::LaunchUIAction()
1. Returning NS_ERROR_FAILURE in PaymentRequestService::RespondPayment() when
the specified PaymentRequest does not exist in PaymentRequestService.
2. Renaming "cleanup" to "close" in DOM::WebPayment codes to fit the actual
behavior.
Mostly testing that they work, and that they record what we expect them to
record, that is, the actual property that was parsed, and not the properties
that it'd resolve or expand to.
That may be another tricky part for CSSOM, I think style setters would fail an
alias test if implemented with the current setup (we do the property lookup in
C++).
Differential Revision: https://phabricator.services.mozilla.com/D3829
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
Browsers can switch at runtime from remote to non-remote and vice versa,
which on the C++ side is detected from a XBL binding change which causes
nsIRemoteBrowser to either be implemented or not. Custom Elements can't
change at runtime in the same way, so unifying on a single [implements]
will allow browser (both remote and non-remote) to be migrated to a single
Custom Element.
To keep current functionality, this updates Qi calls into nsIRemoteBrowser
to instead Qi into nsIBrowser and check isRemoteBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D3346
--HG--
extra : moz-landing-system : lando
Let PaymentRequest inherit from nsIDocumentActivity interface.
Calling RegisterActivityObserver() and UnregisterActivityObserver() in
constructor and destructor to get activity notifications from document.
When receiving the notification, NotifyOwnerDocumentActivityChanged() will
check the owner document's activity status. If the status is disabled, calling
PaymentRequestManager::CleanupPayment() to cleanup the PaymentRequest in
content process and aslo sending the cleanup information to chrome process.
It might be possible that we can check whether an animation is being tracked
by the pending animation tracker without this function to count layout flush
since we force to flush layout if there is any pending animations [1]. But
it will probably result complicated test cases. So to make test cases simple,
we introduce a new function which just checking whether a given animation is
being tracked by the pending animation tracker.
[1] https://hg.mozilla.org/mozilla-central/file/3d20b0701781/layout/base/nsRefreshDriver.cpp#l1957
MozReview-Commit-ID: 4lWuOYCucaD
--HG--
extra : rebase_source : a42866d1b9828820c112ac8f756372648da8763f
And make DOMWindowUtils.getOMTCTransform work for opacity animations' layer.
MozReview-Commit-ID: 7P99WjYqPr0
--HG--
extra : rebase_source : cf87e8da40cf9febdb4188f4ef8ebe3b64eabe53
Unlike GetOMTAStyle, this function returns the transform value including both
of animation and APZ values. Also this function doesn't work on WebRender.
MozReview-Commit-ID: 4zvxKebD29V
--HG--
extra : rebase_source : d8350d256d22a8b76a9762bea21cfd1e87928c4a
