Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Now, callers of EventUtils.synthesizeKey() don't need to specify
KeyboardEvent.code value anymore if they assume that active keyboard layout
is US keyboard layout.
Note that this patch changes the meaning of only test_bug551434.html.
Some callers in it don't match the key value and code value but that looks
like that they don't checking such odd keyboard events. So, they must be
bug of the test.
MozReview-Commit-ID: Itxo7yZ9rkK
--HG--
extra : rebase_source : 856ef3715c924ca16e993ea57d92d1243b5cc6be
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Previously this was safe, as the synthesized mouse event would be processed in
the child process, updating the focus state, in order - before the content
process would try to check its focus state. Now, thanks to multiple event queues
work, this isn't guaranteed.
This patch just adds retrying to the logic, so we retry up to 10 times, 100ms
apart. This should ensure that we don't incorrectly detect a test failure
intermittently.
MozReview-Commit-ID: J4uzl9jeafC
With JSM global sharing, the object returned by Cu.import() is a
NonSyntacticVariablesObject, rather than a global. Various code tries
to use properties from a JSM global via an import.
Cu.importGlobalProperties can also be used in some places.
MozReview-Commit-ID: HudCXO2GKN0
--HG--
extra : rebase_source : 6b5fa6f5509397504cb461a761f6cc2399f18c40
The e10s tests were written assuming a world where ContentTask.spawn and
LocalStorage were both PContent. Also, that Quantum DOM labeling wasn't
something to worry about. These assumptions no longer held, resulting in
the test intermittently failing if all changes hadn't propagated via
PBackground to the tab under test by the time the ContentTask.spawn
state retrieval call made it to the tab's main thread.
This has been corrected by using "storage" events where already in use and
polling where not in use. Plase see the added comments for more details.
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 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
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
This was a little tricky to get right. The "spin the event loop" bit is weird
but doing a setTimout to call resolve is already redundant since resolve calls
the promise callbacks on the next turn of the event loop anyway. Basically,
the test just needed to move more stuff to the content process.
MozReview-Commit-ID: KrZZU5reJf7
--HG--
extra : rebase_source : 0817cdefc2e3941a5f59e3e8365d72395d8c4869
There are a series of tests strewn about the tree that seem to exercise window
opening in one form or another, so I thought I'd put them under a tag.
MozReview-Commit-ID: 74JwLUTzaMU
--HG--
extra : rebase_source : 87439bacd9643ab63d015f58f44af2f8a74675a0
extra : source : 9d903a6a12aa7182252ec3e220c89b569c14e11b
There are a series of tests strewn about the tree that seem to exercise window
opening in one form or another, so I thought I'd put them under a tag.
MozReview-Commit-ID: 74JwLUTzaMU
--HG--
extra : rebase_source : 0c92084914ffe44a781f034b2416e17905656607
- the test case was failing because of an additional error message which is logged only on DevEdition.
- this patch makes the assertions on the cached messages more resilient to this kind of changes in the logged messages, by filtering the cached messages and then making assertions on the length of the messages found.
MozReview-Commit-ID: GIPOkWzM9Bo
--HG--
extra : rebase_source : ba0b92859105afcc6f2101a95e74b99b5a3f9aae
Previously, every test and support file would be synced to the objdir
when running any test. Now that only those support files and tests requested
are synced, we note support files required beyond those in a test's
directory in ini manifests.
MozReview-Commit-ID: EmlDz9d4lqt
Save the originAttributes of the current principal into the console events,
so that we can filter the console messages by originAttributes (e.g.
WebExtensions console events can be filtered using the addonId that the
ExtensionPages' originAttributes contain.
MozReview-Commit-ID: 5v9BWLbgskd
--HG--
extra : transplant_source : %2C%A1%D4%8AEp%E6G%8A%2C%DA%A8%EE%B3%EA%0E%84xk%FF
This will make sure that window.scrollbars correctly reflects the respective
chrome flags in e10s mode.
We also update nsXULWindow::SetContentScrollbarVisibility() to the new
nsContentUtils helper. That code is responsible for doing this work in the
single process case.
This will make sure that window.scrollbars correctly reflects the respective
chrome flags in e10s mode.
We also update nsXULWindow::SetContentScrollbarVisibility() to the new
nsContentUtils helper. That code is responsible for doing this work in the
single process case.
The timeout timer of a geolocation request holds a strong reference to
the request. This can cause the window to leak if the request is not
completed before the tab containing the window is closed.
To fix this, I made the timer instead hold a strong reference to a
wrapper class that has only a weak reference to the request. The
request destructor must now cancel the timeout timer.
I also outlined a call to StopTimeoutTimer() in
nsGeolocationRequest::Shutdown().
The timeout timer of a geolocation request holds a strong reference to
the request. This can cause the window to leak if the request is not
completed before the tab containing the window is closed.
To fix this, I made the timer instead hold a strong reference to a
wrapper class that has only a weak reference to the request. The
request destructor must now cancel the timeout timer.
I also outlined a call to StopTimeoutTimer() in
nsGeolocationRequest::Shutdown().