The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
When eKeyPress event is dispatched from TabParent to a remote process, it
should store edit command for all editor types. Then, copied
WidgetKeyboardEvent in the remote process doesn't need to request the edit
commands when its ExecuteEditCommands() is called.
Note that this patch also changes a automated test, browser_bug1316330.js,
that uses nsIDOMWindowUtils.dispatchDOMEventViaPresShell() to dispatch
repeated keyboard events in the tab. However, it should use synthesizeKey()
to emulate everything of native keyboard events and the API can dispatch
repeated keyboard events too. (And the test has a bug. It tries to wait 0.5
sec when every keydown or keypress event. However, it fails since startTime
is never initialized. This patch fixes this bug too.)
MozReview-Commit-ID: IYhyxqH3Ch8
--HG--
extra : rebase_source : 0db911e8e6ea7fc537bda76f4cc0f8952cc13dd2
Discussion at <https://github.com/whatwg/dom/issues/319>. In short, the
specification used to say to throw sometimes InvalidCharacterError and
sometimes NamespaceError, but browsers disagreed on which to throw in
corner cases, and everyone agreed it wasn't worth the effort to spec the
distinction, so we just changed it to InvalidCharacterError across the
board.
The test changes are already upstream.
MozReview-Commit-ID: AWSZBznQprG
--HG--
extra : rebase_source : 2f0051f48124380f17300a38ceb8c2ab23015ca1
By using ContentTask, we get a Promise that resolves once we've heard confirmation from
the content process that the ContentTask function has completed running. This means we
can be certain that browser_beforeunload_between_chrome_content.js has had the beforeunload
event handlers added before attempting to unload the page.
MozReview-Commit-ID: DhoTsOZ4BNk
--HG--
extra : rebase_source : ee31ed4e9a8fe0b734a5961c8b0d47d75ccb6703
Other browsers do not support any of these (IIRC), telemetry reports
essentially zero usage, and supporting them is contrary to the DOM spec.
Notes on specific events:
CommandEvent and SimpleGestureEvent: These are not supposed to be
web-exposed APIs, so I hid the interfaces from web content too
(necessary to avoid test_all_synthetic_events.html failures).
DataContainerEvent: This was a non-standard substitute for CustomEvent
that seemed to have only one user, so I removed it entirely and switched
the user (MozillaFileLogger.js) to CustomEvent.
ScrollAreaEvent: This is entirely non-standard, but we apparently expose
it deliberately to web content, so I didn't see any reason to remove it
from createEvent.
SimpleGestureEvent and XULCommandEvent: Can still be created from
createEvent(), but not by content.
TimeEvent: This is still in because it has no constructor, so there's no
other way to create it. Ideally we'd update the SMIL spec to add a
constructor. I did remove TimeEvents.
MozReview-Commit-ID: 7Yi2oCl9SM2
--HG--
extra : rebase_source : 199ab921acfc531b8b85e77f90fcd799b03c887b
The dialog functionality of the non-standard window.find API has been broken
with e10s since it shipped, and bug 1182569 or bug 1232432 (or both) have
broken it for non-e10s.
This patch remove showDialog support entirely, for both e10s and non-e10s,
in a more deliberate way. We now ignore the argument.
MozReview-Commit-ID: 1CTzgEkDhHW
--HG--
extra : rebase_source : 9aa9623ef649fb2c42ad22738130c361acf6b8cc