1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
--HG--
extra : histedit_source : 8426da9c1d070daa35623b3431341c13cb361aed
1. Add a new attribute nsIPaymentOptions.requestBillingAddress.
2. Add new XPCOM interfaces MethodChangeDetails, GeneralChangeDetails and
BasicCardMethodChangeDetails for passing the method change details from
UI code.
--HG--
extra : histedit_source : 680bff71f0d8a9d9333a3699fcc6a4fd9630fe1b
This sends a sync IPC message to the compositor after each crashtest, to
ensure that any stuff inflight in the compositor settles down. In
particular this should round-trip through all of the relevant compositor
threads (i.e. for WebRender it should ensure the scene builder, render
backend, and renderer threads all get flushed).
Differential Revision: https://phabricator.services.mozilla.com/D13033
--HG--
extra : moz-landing-system : lando
Previously, the tabindex attribute wasn't supported on non-control XUL elements at all.
The only way to make those focusable was to use -moz-user-focus: normal.
However, that caused the element to be included in the tab order; there was no way to make it focusable but not tabbable.
This can now be achieved using tabindex="-1".
This will primarily be useful for buttons on toolbars, which will be grouped under a single tab stop for efficiency.
For consistency, this also changes the behaviour of tabindex="-1" with -moz-user-focus: ignore on XUL controls.
Previously, -moz-user-focus: ignore would override tabindex="-1", making the element unfocusable.
Now, the tabindex attribute always overrides if explicitly specified.
Differential Revision: https://phabricator.services.mozilla.com/D12000
--HG--
extra : moz-landing-system : lando
In order to know whether we have temporary autoplay permission without creating a request, we need to
cache its state in the outer window so that we can get the correct returned value for AutoplayPolicy::IsAllowedToPlay().
Differential Revision: https://phabricator.services.mozilla.com/D7013
--HG--
extra : moz-landing-system : lando
This field was originally added for the b2g-only DeviceStorage API,
and isn't used for anything else right now.
This reverts the remaining parts of bug 1043136 and bug 1043136
as well as some support code for mobile.
Differential Revision: https://phabricator.services.mozilla.com/D10014
--HG--
extra : moz-landing-system : lando
In original design, payment method response data is passed between processes
through a simple nsString. It means a special encoder/decoder is needed for
special response data, ex. BasicCardResponse, to serialize/deserialize
into/from the nsString. However, when a token spliter, ':', ';' and '@', is
used in response data, it makes the encoder/decoder can not work normally.
It is hard to define a suitable token spliter set for encoder/decoder.
So instead of using an error-prone encoder/decoder, this patch defining a new
IPC structure for response data.
--HG--
extra : rebase_source : 4972033516bc861ea3f975a27b7688fc6eb89a94
In original design, payment method response data is passed between processes
through a simple nsString. It means a special encoder/decoder is needed for
special response data, ex. BasicCardResponse, to serialize/deserialize
into/from the nsString. However, when a token spliter, ':', ';' and '@', is
used in response data, it makes the encoder/decoder can not work normally.
It is hard to define a suitable token spliter set for encoder/decoder.
So instead of using an error-prone encoder/decoder, this patch defining a new
IPC structure for response data.
This implement a helper API to guess keyCode value of a printable key with
assuming active keyboard layout is US-English. The reason why this stops
computing key value from key value is, most users of such API probably want
to emulate input from US-English keyboard layout if they don't specify the
detail. Therefore, the new API simply maps each ASCII character to a
DOM keyCode which is usually mapped in US-English keyboard layout.
Differential Revision: https://phabricator.services.mozilla.com/D5515
--HG--
extra : moz-landing-system : lando
We need to port synthesizeKey() of EventUtils.js to FuzzingFunctions. So,
its helper function, _guessCodeFromKeyName() in EventUtils.js needs to be
accessible from FuzzingFunctions. Therefore, we need to reimplement it
with C++ and make it accessible via nsITextInputProcessor for EventUtils.js
for making easier to maintain.
This patch moves _guessCodeFromKeyName() into TextInputProcessor and
WidgetKeyboardEvent. Non-printable key part of _guessCodeFromKeyName() is
moved to WidgetKeyboardEvent::ComputeCodeNameIndexFromKeyNameIndex() because
of not depending on active keyboard layout. On the other hand, printable
key part needs to assume that active keyboard layout is en-US keyboard layout.
Therefore, it's moved to
TextInputProcessor::GuessCodeValueOfPrintableKeyInUSEnglishKeyboardLayout()
because any Core code shouldn't refer it as utility method for keeping that
we're i18n-aware.
Differential Revision: https://phabricator.services.mozilla.com/D5514
--HG--
extra : moz-landing-system : lando
Our current prioritization mechanism doesn't account for tab
warming, or for the fact that the current tab should be
deprioritized. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D7205
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
This is an old B2G leftover. The directory isn't even traversed by the build
system.
--HG--
extra : rebase_source : 7b659ba1a03e9d830af1a6b959987dfb585ce704
1. Add PaymentValidationErrors and PayerErrorFields in PaymentRequest.webidl
and PaymentResponse.retry() in PaymentResponse.webidl
2. Implement PaymentRequest.retryPayment() and
PaymentRequestManager.retryPayment() in content process.
3. Add IPCPaymentRetryActionRequest in PPaymentRequest.ipdl to transfer the
error fields to chrome process.
4. Implement PaymentResponse.retry() by reusing the code of show() and
updateWith() of PaymentRequestService in chrome process.
Remove the unnecessary XPCOM component nsIPaymentActionRequest and
nsIPaymentActionCallback. These two components are only used in C++ and they
need not to expose to the front end.
1. Add a new method nsIPaymentRequestService::ChangePaymentMethod for UI to
inform merchant the payment method is changed by user.
2. Add a new method in PPaymentRequest.ipdl to passing the changing method
information from chrome process to content process.
3. Add BasicCardChangeDetails dictionary in BasicCardPayment.webidl
4. Create ChangeDetails, GeneralDetails and BasicCardDetails for saving the
the method information in content process.
1. Add a new attribute nsIPaymentOptions.requestBillingAddress.
2. Add new XPCOM interfaces MethodChangeDetails, GeneralChangeDetails and
BasicCardMethodChangeDetails for passing the method change details from
UI code.
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()
