Android sets dom.disable_window_showModalDialog to true in mobile.js so this
test now fails because it explicitly sets the pref to false. For the time
being, it's easiest to simply skip this test on Android and turn it back on
once we remove the test entirely.
MozReview-Commit-ID: 5XsiXupESvg
--HG--
extra : rebase_source : 8d176e069aac5cc49ec06b7055be5a81b45c188a
Annoyingly, setting the pref doesn't magically make the function appear on the
current window, so we create an iframe and retrieve it from there.
MozReview-Commit-ID: 9fOr4YJOzXh
--HG--
extra : rebase_source : d23643b388538955cc831a3b6e1473232ab5498a
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 : b6573f8e2001f91d0e5a50f6376b191459549e94
extra : intermediate-source : 0411e687044ecc7b56684196238e6e6e68a9d685
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The intermittent failure appears to have been due to mOriginsHavingData
only being updated when the db thread flushes. The db thread has a
hard-coded 5 second flush interval. It's likely that e10s startup was
previously so slow that we were assured of having a flush happen by the
time our fresh process created its parent actor.
We correct this by reliably ensuring a flush before spinning up the
process to check preload state. We also ensure a flush at the start of
the test for our check that there was no preload in the initial cases.
We were actually more vulnerable in that case, I believe, but as a
browser chrome test, there were no other tests that would have used
content localStorage.
We additionally ensure that the content process has received and
populated mOriginsHavingData by having the tab opening process wait for
about:blank to load in the process before actually opening our origin.
Prior to this change we were depending on orderings that aren't
guaranteed.
--HG--
extra : rebase_source : 92d3c675cee82ffe8b562e83860601e0c6dc1a9b
Bug 1345990 introduced a "forceNewProcess" argument in
BrowserTestUtils.openNewForegroundTab. By switching to this we can
stop bloating the process count pref to try and produce equivalent
results. To minimize test churn and because it doesn't really hurt to
double-check, the code that asserts that our tabs are each in different
processes and related book-keeping infrastructure have been left intact.
We also set a preference to disable preallocated processes in the interest
of maximizing test consistency and minimizing breakage. It's conceivable
that a preallocated process might end up creating its StorageDBParent
actor prior to when we want, breaking things. By ensuring the process
isn't created until we want it, we avoid a lot of brittleness.
--HG--
extra : rebase_source : 5736f7b2d06b720cefbe82eb6052e71b9fc14f23
This patch is for the intermittent bug 1357082 which has a failure in the test 'test_pointerlock-api.html' and is more frequent when it is run on Ubuntu 16.04. This failure is resolved by retrying the mouse movement until it actually occurs.
MozReview-Commit-ID: 9XC4zmWj8Gn
--HG--
extra : rebase_source : 8f2d80661f8da82a68eeade2261a2d729c13c84d
This is necessary because we asynchronously send the updated UserContextId back
from the child to the parent process, and we would occasionally lose the race on
infrastructure causing us to see the non-updated version.
With this change we explicitly ask the content process, which is not racey.
MozReview-Commit-ID: LODNi1YmBI8
This replaces the JS policy service stubs with a pure C++ version which
directly makes policy decisions based on active WebExtensionPolicy objects.
This is the first step in a larger refactoring, which will remove the
ExtensionManagement module entirely, and replace the current add-on policy
service with direct, non-virtual access to native WebExtensionPolicy objects.
It will also be followed by related changes to migrate the content script and
extension page matching to native code, based on the existing MatchPattern and
WebExtensionPolicy bindings.
MozReview-Commit-ID: 2MpbmXZGiPZ
--HG--
extra : rebase_source : 8b268618164b45605143e858665e592de829a6fa
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