Removes the XPCOM interface for nsIDOMHTMLMenuItemElement, replacing it
with binding class usage.
MozReview-Commit-ID: 9HtCmwKyV1W
--HG--
extra : rebase_source : d56ee91a46d48c9d8698765b520a585361813a26
2017-10-12 15:10:50 -07:00
Matt Woodrow ext:(%2C%20Miko%20Mynttinen%20%3Cmikokm%40gmail.com%3E%2C%20Timothy%20Nikkel%20%3Ctnikkel%40gmail.com%3E)
The two happening at the same time can lead to the APZ autoscroll being
cancelled due to APZ receiving a main-thread scroll offset update.
To achieve this:
- The content process assumes APZ is handling the autoscroll until
told otherwise.
- If the parent process knows APZ won't handle an autoscroll, it
tells the content process via its response to the Autoscroll:Start
message. This covers all cases where APZ doesn't handle the
autoscroll, except the case where APZCTreeManager itself rejects
the autoscroll and it lives in the compositor process rather than
the parent process.
- If APZCTreeManager rejects an autoscroll and it lives in the
compositor process, it sends an 'autoscroll-rejected-by-apz' message
to the content process.
MozReview-Commit-ID: L62v4COai6W
--HG--
extra : rebase_source : bc4c6417e77461634263defb88e67ed5036c454e
In the current blocklist implementation, we read the stylo blocklist from the user
preferences very early and only once, even earlier than the test preferences
updating happens.
So, to be able to test the functionality of the stylo blocklist, we add these two
nsIDOMWindowUtils APIs to be able to add/remove a mock domain to the existing
blocklist.
MozReview-Commit-ID: K48ejLBcNbn
--HG--
extra : rebase_source : 354fe9871231f2a94f09bd2612c9d21ced4143e8
Removes the XPCOM interface for nsIDOMHTMLCanvasElement, replacing it
with binding class usage.
MozReview-Commit-ID: DQJhqGlY8U6
--HG--
extra : rebase_source : a33146a22ee356a0840bb9fef82d51b2b315f6d7
Removes the XPCOM interface for nsIDOMHTMLAreaElement, replacing it
with binding class usage.
MozReview-Commit-ID: IaX4JFTPZn6
--HG--
extra : rebase_source : 79f9200c6ff9e081a5d9bc21eaa605f88caa99e9
It has no users in mozilla-central or comm-central. This also lets us remove
nsBaseWidget::GetCursor().
--HG--
extra : rebase_source : 3875ce37c78f82285c4e5dbd8133e9ae3dafa0de
Removes the nsIDOMHTMLObjectElement XPCOM interface, replacing it with
HTMLObjectElement and FromContent conversion usage.
MozReview-Commit-ID: dmsjSO97uh
--HG--
extra : rebase_source : 9b2c25b8681f754bc34233afccdb6fc5d38f0804
1. Create a new action response status PAYMENT_NOTSUPPORTED and get rid of
unnecessary method isAccpeted() from nsIPaymentActionResponse.idl.
2. Create canMakePayment() in PaymentRequestService and run it before
launching UI. If canMakePayment() returns false, send PAYMENT_NOTSUPPORTED
back to content process.
3. If chrome process returns PAYMENT_NOTSUPPORTED when calling showPayment(),
throw NotSupportedError DOMException to merchant side.
Getting the top level document's principal when constructing PaymentRequest,
then sending it to chrome process and saving it in nsIPaymentRequest.
Creating a new readonly attribute nsIPrincipal topLevelPrincipal in
nsIPaymentRequest for UI to query the top level document's principal
information.
When creating new windows/tabs from the content process, we currently choose
the default remote type based on the referrer URI, rather than the actual
remote type of the opener. While this generally works, it fails when opening
windows from URLs (particularly in iframes) which are opened in process types
other than their default process type, since the initial about:blank load gets
redirected to a new process before the child process has a chance to load its
actual target URI.
Using the actual remote type of the child opening the window fixes this
problem for URLs which are capable of being loaded into the child's process
type.
MozReview-Commit-ID: ClxVGxu52Lf
--HG--
extra : rebase_source : 3a029d207dac0b08eb7c7ce7737adfd9c1c96892