By the webdriver spec both commands have to return a list of strings for the
window handles. Right now those are numbers.
MozReview-Commit-ID: 5Gn624BaVI1
--HG--
extra : rebase_source : 400acb7a0cc4bc1b1bf09934959a63da1bb5a28c
setWindowRect is using `return` from a generator which is not valid
javascript. This now populates the response before it is returned to
the client.
MozReview-Commit-ID: 6vSadp59Nrt
--HG--
extra : rebase_source : d642771dd2308c21d1e3398b7387b4ae4e5ffeea
The maximizeWindow call in Marionette uses return which is not valid javascript.
This change update the response that is then picked up by the server before
returning to the remote end.
MozReview-Commit-ID: JJzsTHba0AK
--HG--
extra : rebase_source : 8b64aa37c7391d60a9de3276cef89a5564bbcd37
To allow update tests to use source builds of Firefox before bug 1355888
was landed, the MOZ_MARIONETTE environment variable has to be be
pre-emptively set. Otherwise Marionette will not be activated after
the update has been applied.
MozReview-Commit-ID: Hqb6SjYtOPR
--HG--
extra : rebase_source : 10f9b4d2545198fc95294381ec1db63f1445c736
We currently use:
> '64' in platform.architecture()[0] # architecture() returns (bits, linkage)
Unfortunately, that is the Python binary byte size.
https://docs.python.org/2/library/platform.html
> platform.architecture(executable=sys.executable, bits='', linkage='')
>
> Queries the given executable (defaults to the Python interpreter binary)
> for various architecture information.
>
> Returns a tuple (bits, linkage) which contain information about the bit
> architecture and the linkage format used for the executable.
Instead we should be using machine()
> platform.machine()
>
> Returns the machine type, e.g. 'i386'. An empty string is returned if the
> value cannot be determined.
My sampling size:
* win10 - AMD64
* win7 - x86
* Linux64 - x86_64
* MacOSX - x86_64
MozReview-Commit-ID: HVBRHUGP1J2
--HG--
extra : rebase_source : 729f581dfa8244e3055cc0c383760444850ccdfa
This adds support for fetching Python3 zip files
for Talos for Windows 32-bit and 64-bit.
MozReview-Commit-ID: KpYXQrfwRBY
--HG--
extra : rebase_source : e31530c45ab24e98a2b0ac6d51d7956b204df5b0
Bug 1360550 resulted in the buildid the Linux builds had being different than the directory they were uploaded to. This had fallout affects for QA's firefox-ui tests and presumably anything using mozdownload.
MozReview-Commit-ID: 7xbEihhDF1N
--HG--
extra : rebase_source : 5b857887722e172695eb1f0fb12361fc89c24f80
Because of bug 1338651, we need to stick to BBB macosx64 builds for now.
MozReview-Commit-ID: AwQc5r6ikUN
--HG--
extra : transplant_source : %97%1B%95H%D8L1%87%84h%F4%89%0D%283w%98%7E%2C%F4
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
Removes references to now unused pref that was added in bug 868441 and removed in bugs 913807 and 1054572. It also removes some leftovers from http channel which have not been removed in those 2 bugs.
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : f83472bc1c88dd0deadbe485d9002499027ff07f
Using only the different unload events to detect a page load is
unreliable because of a possible delay in starting the navigation,
which could be triggered by a slowness of the application.
By using 'beforeunload', an event will be received much earlier,
and the unload timer can be extended to a couple more seconds to
wait for the navigation request to start.
If a website has it's own 'beforeunload' listener registered,
a tab modal dialog will be opened by Firefox, and Marionette
returns from the currently active command immediately to allow
the test to handle the dialog.
MozReview-Commit-ID: 6ZUYtFJSSnz
--HG--
extra : rebase_source : 3f7b9d9d0067ed7c65a3bb8774f0a5ae8bc702c2
Windows systems only accept singled-dashed -marionette, whereas Unix
platforms accept both that and double-dashed --marionette. This makes
the documentation true for all supported platforms.
MozReview-Commit-ID: IG7ir2HVoHo
--HG--
extra : rebase_source : f3b2740e47f373e5f784d131f1844f82b4c56990
To preserve backwards compatibility for in-app restarts using
Services.startup.quit(eRestart), we want to continue using the
marionette.enabled preference in the Python client until the patch
introducing the MARIONETTE environment variable (preceding this) makes
it into an official release.
This is due to the fact that the Marionette Python client is being
used for upgrade tests, and it is needs to stay compatible with all
release trains.
MozReview-Commit-ID: KstsJRu4lIP
--HG--
extra : rebase_source : 01a00549a9c8b57fd65aad8cd68ef04fdcca981d
There are no current use cases for starting and stopping the Marionette
server at runtime through a preference. Since it is possible for
arbitrary addons to modify any preference, we are removing it to reduce
the potential attack surface for Marionette.
This effectively leaves only three ways of starting Marionette:
By passing the -marionette flag to the Firefox binary at startup,
setting the MOZ_MARIONETTE environment variable, and by calling
server.TCPListener#start(), which is an internal chrome API.
MozReview-Commit-ID: 9zKsV8ufySU
--HG--
extra : rebase_source : c0914f2ab99229d507830bbf9704e82bd83b1883
This patch introduces a new environment variable, MOZ_MARIONETTE, which
if set will start the Marionette remote control server. This is meant
to be analogous to passing the -marionette flag to the Firefox binary.
When the server is started, we set the environment variable to
preserve Marionette's enabled state across internal restarts.
When Services.startup.quit(eRestart) is called, Firefox is restarted
without the original command line flags it was started with, which means
we lose track of whether Marionette was enabled. By setting
MOZ_MARIONETTE in-process, we preserve the knowledge of this state.
This approach is in line with how state is preserved across in-app
restarts in toolkit/xre/nsAppRunner.cpp:4761 (XRE_PROFILE_*), and for
how MOZ_APP_RESTART and XUL_APP_FILE works.
MozReview-Commit-ID: Dcb34m6FoZh
--HG--
extra : rebase_source : 98515c702dfd8eaad01f7eab06d33124ce14b15c
The "generate-build-stats" mozharness action collects a bunch of build
system metrics, including build_resources.json, ctors count, and
installer size and reports them by writing special messages that
log parsers read.
Before this commit, this mozharness action occurred sometime after
"build." But relative ordering to other actions was not consistent
and appears to be significantly cargo culted.
4e61e69a383c (bug 1304508) changed the "check" mozharness action to
invoke `mach build check` instead of `make` directly. An unintended
consequence of this is that `mach build` replaced the
build_resources.json file from the build itself with one measuring
`make check`. This made the "build time summary" metric take a nose
dive.
This commit works around the issue introduced by 4e61e69a383c by
reordering the mozharness actions so "generate-build-stats" follows
immediately after the "build" action. Not only does it now occur
before the "check" action, but it also occurs before uploading and
other actions.
I'm not sure why "generate-build-stats" is its own action and not
part of "build" itself. As the diff shows, numerous instances of
"generate-build-stats" are commented out, which means we aren't
collecting metrics. "generate-build-stats" is also missing from a
handful of mozharness configs, including Windows Clang builds. I'm
not sure what the history is (it is likely varied and almost certainly
involves a fair amount of cargo culting), but I think it is a bug that
we aren't collecting build metrics for every build. I would like to
fix this. And moving "generate-build-stats" immediately after "build"
should make that transition easier.
MozReview-Commit-ID: 7jNTVWRvMnh
--HG--
extra : rebase_source : 0b5fd1f462caa5c283ba7e1b693fdc5b8b948add
Our click + page load implementation doesn't handle complex navigation
scenarios yet. As such those should not be triggered inside our unit
tests.
MozReview-Commit-ID: Cog5vohttes
--HG--
extra : rebase_source : 7068483f041ab1895ecc921f377da9bfd420ec23
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : 34aa762917566b052ade6372280caed72fbfbe9a
Because DevEdition builds are intended to be shipped, we must force clobbers on all of them. We also need to fix the update channel, which is currently still set to "beta". In order to make it possible to override this we need to change stage_platform to a unique value.
--HG--
extra : amend_source : 84422951ad22665c1cf027882171db01953ff840
To make OS X and Windows DevEdition builds upload to the "devedition" area on archive, instead of "firefox".
--HG--
extra : amend_source : b5472a9c2f27aa59b7f8715800dcb2161fe4252f
Since lengthPairType and positionType share the same testing logics, we shall
just reuse lengthPairType::{testInterpolation, testAddition} for positionType.
MozReview-Commit-ID: 1nBBHmTB3U9
Similar to the other unload and load events during a page load,
the hashchange event should only be handled if the event's target
document is the current window.
MozReview-Commit-ID: F1LMBh5Cy4A
--HG--
extra : rebase_source : 668fd6946067989e7e732b24baf6de2e85541f21
originalTarget seems to be outdated and not used anymore for each
navigation related event. But target is, and as such handleEvent
has to make use of that instead.
MozReview-Commit-ID: AN2H1PbCt7A
--HG--
extra : rebase_source : fbead2b5b802454f0e288fb9696db5d422e46b50
We shouldn't be running pymake any more. So code to work around its
behavior is no longer necessary and can be removed. Good riddance.
MozReview-Commit-ID: AlV6ZLiA6WB
--HG--
extra : rebase_source : 56252a8d96f108fd24878e7a26f0d4ffe4a0db45
Now that mozharness is calling `mach build` to invoke the "check" target,
there are no more consumers of the "enable_pymake" config option. So we
remove it from the configs.
We also remove definitions of the "make" executable referring to pymake.
The only call sites I could find for "query_exe('make')" are in
testing/mozharness/scripts/mobile_l10n.py. So most of these definitions of
the "make" executable appear to be a cargo cult or left over from a
previous rewrite (the code we just changed to stop calling "make" wasn't
using query_exe). Since mobile_l10n.py is still using query_exe() to find
the make executable, there's a chance switching away from pymake (if this
patch even does that - I don't think we touched a config file related to
that script) could break something. I'm fine with teasing out that bug.
MozReview-Commit-ID: 7HR6ShAKcoV
--HG--
extra : rebase_source : 07c6a6f7aaab6d7fceeab46b6ca2744c964148dd
We switch mozharness to use `mach build` to invoke the "check" make
target instead of using `make` itself. Because `mach` is the interface
that everyone should use and `make` is an implementation detail.
My editor also snuck in a change to normalize a CRLF line ending.
MozReview-Commit-ID: 4gdE6oeK0Lz
--HG--
extra : rebase_source : 0bfd6503a25f6b4304b596bd59ef99294c011474
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
Because individual <option> elements are painted and represented in the
DOM when they belong to a <select multiple> list, the center point of
the list might be one of the options.
To take this into account, we perform an inclusive descendant check
(DOMElement.contains) to see if the <option> element is a descendant of
the container <select> element.
In the case the targetted element is the element itself, the test will
still pass since it is an _inclusive_ descendant check. In other words,
containerEl.contains(tree[0]), if tree[0] is equal to containerEl,
will pass.
The relevant specification changes were made in
40abcefd6a.
MozReview-Commit-ID: ORX8zLxQJ
--HG--
extra : rebase_source : 87ca38df6696257d569ef1ffcb888426d1f569af
There appear to be no in-tree users of this function and it references
"b2g." I'm pretty sure it is dead code.
MozReview-Commit-ID: EHHRQ2iqQoP
--HG--
extra : rebase_source : ec136063dc5e4243232fce5289a8f47bd925b481
We shouldn't be running any Firefox OS automation.
MozReview-Commit-ID: 4ea9SL7jill
--HG--
extra : rebase_source : 6d5c457d14d9d2b2b4abda47a2b3bfa1fa745d36
We shouldn't be running any automation related to Firefox OS. We should
be able to delete these files.
MozReview-Commit-ID: SY5f0GD9NQ
--HG--
extra : rebase_source : 3b7b5b28bc5da554ad9082c1c3115b3ab8de2e0a
These were the last occurrences of "gaia" in the mozharness directory.
MozReview-Commit-ID: 8ACEw1rMoUS
--HG--
extra : rebase_source : b5d98c9166d75a83f5303ee0faa34484b6f998d3
So far, we don't have a type to test anamations of a pair of length.
Since border-spacing consists two absolute lengths, we shall add this
new type.
MozReview-Commit-ID: Bo8VMWPLDHc
--HG--
extra : rebase_source : 26439e622fac5806465e971b84a111c9e01ffe1e
When refactoring the tests for the Set Window Rect command, it was
discovered that the Maximize Window command was not synchronous.
This patch makes GeckoDriver#maximizeWindow synchronous by waiting for
the DOM resize event to fire before returning the window rect to the user.
It also aligns the command with the WebDriver standard by making it
restore the window to its original size when calling the command a
second time.
MozReview-Commit-ID: Ft3tn2A4m7u
--HG--
extra : rebase_source : 52b523e53dd19cc8bdc4631382c96db5906f333a
When the window's size is being set to the window's existing size,
Marionette unconditionally listens for the DOM resize event. When a
window is not resized, no such event fires.
This patch skips setting the window size when the window's current size
is the requested size. This bypasses the problem of listening for an
event that never occurs.
It also combines the window position- and size tests into a
test_window_rect.py test, since they share many of the same
characteristics.
Fixes: https://github.com/mozilla/geckodriver/issues/643
MozReview-Commit-ID: IUtCFXwT1fh
--HG--
extra : rebase_source : 43c4d0e24cf1e0dc6102af48b8fe6f075b6dd4a2
The test assumes the click point is the centre of the element, whereas
WebDriver uses the _in-view_ centre point to perform clicks.
If parts of the element is rendered outside the viewport, the click
point is calculated from visible portion of the element that is seen in
the viewport.
This means that if any portion of an element is within the boundaries of
the viewport, it is clickable. If it is not, then it is not interactable.
This change is unfortunately not accompanied with any
implementation changes, but prepares Marionette for the changes
to the Element Click implementation that will come as part of
https://bugzilla.mozilla.org/show_bug.cgi?id=1321516.
MozReview-Commit-ID: Kh0zzRrtmJ4
--HG--
extra : rebase_source : 63cc463a11d5ca085e7a96ea84dcadbe3bb90204
With remoteness enabled content framescripts don't seem to inherit the
appenders for loggers, which have been set by the main script. To get
the output written to stdout they have to add their own appender. To
prevent duplicated output after framescripts get reloaded, the addition
of the appender should only happen once.
MozReview-Commit-ID: A5TMQvQu0Iy
--HG--
extra : rebase_source : 9a9ecdb8aec8d7b310b916407edbac77b8ec88c9
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 1b7905c101b7ebf406e88c73be5d0e069b7342c0
Tests for page timeout durations have to use an HTTPD handler that delays
or slows down document load. Otherwise there a risk that the timeout error
is not returned before the document finishes loading.
MozReview-Commit-ID: HGGcXfCuaSH
--HG--
extra : rebase_source : c79b01ca4e56e21877c6fe94309b7b0424d9b552
In the case when the trigger callback inside navigate() uses a generator,
the code has to be synchronized and needs to wait until the contained
command has been completed.
MozReview-Commit-ID: 8qKUMvH7HpS
--HG--
extra : rebase_source : 19a87058d62088701914ab2a468ddffaecec1fe2
In the case of switching to an in-process frame, the checkLoad timer
is setup which waits for the frame's content to finish loading.
But the command doesn't actually wait for those events and calls
sendResponse() immediately. This causes a race condition for the
following commands.
MozReview-Commit-ID: 6vuQ7paQ55K
--HG--
extra : rebase_source : ceb590f435d84ead4eba2e718e1ebaa01900d33f
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 92870f1adc7ae68e58b15443e4223012bdf0e39a
The CDM process can't allocate shmems itself because it's sandboxed, so we
pre-allocate shmems in the content process and send them to the GMP process for
the CDM to use. Some sites seem to have encoded their content in such a way as
to cause the CDM to allocate and hang onto more frames than we pre-allocate; so
we run out of shmems in the GMP process, and the CDM can't allocate further
buffers to return output, and we fail.
So change the ChromiumCDMChild to allocate non-shmem-backed buffers if it runs
out of shmems, and return the result to the content process as an nsTArray.
Upon receiving that, the parent will send an extra shmem to the child, to
hopefully avoid the slow path again.
Also increase media.eme.chromium-api.video-shmems to 4, so that we're less
likely to hit this slow path in the wild. I've seen that Lightbox.co.nz and
Microsoft's EME test-drive require 4 shmems.
MozReview-Commit-ID: ISQYDkTj5uY
--HG--
extra : rebase_source : 4beba0212411a0f5867feb506bbf732f5a934fa9
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
Note that the UITour library can still show a panel in the event that we want to
promote the feature that way.
MozReview-Commit-ID: FzKSzO987h7
--HG--
extra : rebase_source : 8c129106478559f011a3a4e311331851939ab408
This change makes it possible to click elements that has its
pointer-events style property set to "none".
If an element has its style property pointer-events set to "none",
the element in view test will fail due to document.elementsFromPoint
excluding it due to non-interactability. This is only a problem when
checking if the element is inside the viewport, and not when actually
performing interaction with the element.
The relevant specification change is
ba6ee925b5.
MozReview-Commit-ID: JwZB6fm7P9A
--HG--
extra : rebase_source : 18ddf7955c7e0bc6d1d7f798aebc6e09799a99ca
This makes sure that tests that either specifically want to test fewer content
processes *or* tests that don't work with multiple content processes will get
what they ask for when they run.
MozReview-Commit-ID: 6FI8BmB98Zi
--HG--
extra : rebase_source : 52fbf155fb3d1ae2a9805968aa96761bc27ed0ed
In cases where CPU usage couldn't be recorded, we may incur a division
by 0 exception.
While we should figure out why we're not collecting CPU data, this patch
papers over the uncaught exception which was causing mozharness to bail.
MozReview-Commit-ID: 3PrIl6cEzuf
--HG--
extra : rebase_source : ece317b73af6a5b47ccad30981963457e6c6b9a8
These builds do not have a distinct variant and they do not have an artifact
build equivalent, so specify this in their respective mozharness configs.
MozReview-Commit-ID: CHMglUoP8LR
--HG--
extra : rebase_source : a82323616c8266a6e7d4d82fde0da441da3cc3f3
The previous commit changed our default behavior to make these entries no longer
necessary.
MozReview-Commit-ID: 5bKEH7zbbWi
--HG--
extra : rebase_source : 431d7f6df1136a20ed5796c23832879c5be99790
No builds other than vanilla opt and debug builds are supported by the artifact
code currently, so prevent variant builds from being replaced by artifact builds
by modifying mozharness' replacement logic to replace a build with an artifact
build only when it is a regular opt or debug build or when specified by a
config.
MozReview-Commit-ID: KUUgrbga53l
--HG--
extra : rebase_source : d3c6e3929bf02893ec18f54b0a8739181067e22b
This will make it easier to correctly star these failures, which
otherwise simply show up as a false positive leak.
MozReview-Commit-ID: 5P6AMRyYmtI
--HG--
extra : rebase_source : 6e63bffb6cdcb389d6533acbc44c2a206009a99e
Practical changes:
1) Some additional method arguments are nullable or optional, which
matches Chrome/WebKit. They make more sense non-nullable and
non-optional, but Chrome is afraid of the compat impact of changing.
2) Added [CEReactions] to deleteFromDocument().
MozReview-Commit-ID: Kg9EDubnEui
--HG--
extra : rebase_source : 1d47ee0b12b0b719159c326f789dd6e6b6000c8e
Add preliminary support for returning unexpected alert open errors when
calling commands that require it according to the WebDriver standard.
Also fixes a faulty test that seems to believe it is fine to click an
element whilst an alert is present.
Further work needs to be done on user prompts, asserts, and the handler
for user prompts in https://bugzilla.mozilla.org/show_bug.cgi?id=1264259.
MozReview-Commit-ID: BiWURoQECji
--HG--
extra : rebase_source : caa1506a0e972c7ad0da2d31993fb0b8ecc1ee17
This patch removes the call to element.isVisible when clicking XUL
elements because it does not do anything useful. element.isVisible skips
the Selenium atom.isElementDisplayed check for XUL elements and runs a
few web content/viewport centric tests that always pass in XUL.
It also splits the chrome click out to a separate function to avoid a
few if-conditions.
MozReview-Commit-ID: EkcwT77ku3C
--HG--
extra : rebase_source : ee5e8148934ec008cda996610c20a826f86412af
The window reference may have been discarded as a result of interaction.
For example, this may happen when clicking a button that deletes the
host <iframe> element containing the child window. In this case, the
WindowProxy will set its closed property to true, to indicate that the
browsing context has been discarded.
We only want to flush the event loop of windows that exist, and so we
return early from interaction.flushEventLoop if the window has been
closed.
MozReview-Commit-ID: LtTHQRudKvk
--HG--
extra : rebase_source : e4133ddeed9e89e38fba6e9b8f17544a3546f7eb
We want to take shadow DOM into account when getting an element's
pointer-interactable paint tree.
Marionette is currently unable to determine if an element inside a shadow
DOM host is disconnected from the document because we are constructing
the frame container with only the main document.
MozReview-Commit-ID: IPDi8fQZYRP
--HG--
extra : rebase_source : 8c6757a032342aa6bbe50ef15025a37ac09ae413
Injected script in the Marionette caret selection API used the "default"
immutable sandbox, but we want to run them in the mutable sandbox.
MozReview-Commit-ID: BpbHdDhDtg4
--HG--
extra : rebase_source : 2b710ca483f1732d91527820006da5da331b5df3
Testing the return value is misleading in this case. What we want to
test is that it does not throw due to a permissions issue.
MozReview-Commit-ID: 2Wbwou9opyF
--HG--
extra : rebase_source : 2731ddce0efcd705880a70d69ee934571a766b9a
The Components.classes constructor should throw an error in both the
mutable and the "default" sandbox.
MozReview-Commit-ID: C40nZNaVWwz
--HG--
extra : rebase_source : 81ecde684967241de5fed8f61dd1c0d69d077cfb
We accidentally only ran them in "default" and "system" before, and also
one of the arguments in the system globals test was wrong.
MozReview-Commit-ID: DmBYGsZaIVP
--HG--
extra : rebase_source : 25f72fca677a44079d727e5ff3fa147e3e28eb6e
We were previously missing a test for the arguments variable that is
implicitly exposed to functions.
MozReview-Commit-ID: IC6aJcUsyhd
--HG--
extra : rebase_source : 7aeb986bb4c299ef5996f7b2847e6cc2d878459f
The Python standard library uses tuples to define arguments for functions,
whenever they are invoked through meta programming.
The Marionette client only allows the list type for backwards
compatibility, so we prefer tuples in this case.
Another good argument for tuples is that tuples are immutable.
MozReview-Commit-ID: 72zPzYvBz7Q
--HG--
extra : rebase_source : 79315dd809e00c4c805bd0de3244b519e3ff286f
Marionette does not protect the unloadHandler in
testing/marionette/evaluate.js from content introspection or
modification, which can happen when web frameworks override
window.addEventListener/window.removeEventListener.
The script evaluation module used in Marionette relies on
sandbox.window.addEventListener/removeEventListener to throw an error when
script execution is aborted due to the document unloading itself. If the
window.addEventListener/removeEventListener functions have been overridden
to introspect the objects that are passed, they may inadvertently touch
objects originating from chrome space, such as the unloadHandler.
Because the Gecko sandboxing system put in place strict security measures
to prevent accidental chrome-space modification from content, inspecting
the unloadHandler will throw a permission denied error once the script
has finished executing.
We have found examples in the wild of this in particular with the Angular
web framework. This patch makes the unloadHandler safe for introspection
from web content.
Fixes: https://github.com/mozilla/geckodriver/issues/515
MozReview-Commit-ID: E2LgPhLLuDT
--HG--
extra : rebase_source : 9948585b4ac2f464a9f31868bfd2d5967e61755e
DevTools is about to move out of mozilla-central and be released as an add-on.
So that these protocol files are going to be missing from the tree.
To accommodate that, we are doing a copy of them next to marionette.
MozReview-Commit-ID: 9PyhuwyZyXI
--HG--
extra : rebase_source : b6d96ae5e4c4ac837713e396ab72163b168871f2
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
Previously, replace() and toggle() would not always remove duplicates
and whitespace from the DOM attribute in the case where they were no-ops
(replacing a nonexistent token, force-toggling a token to its current
state). Now they do. This matches the behavior of add() and remove(),
and also replace() in one case (replacing an existing token with
itself).
This follows a spec change: https://github.com/whatwg/dom/pull/444
MozReview-Commit-ID: 7lDEQxOGxPV
--HG--
extra : rebase_source : 842ff24c46681649affcedcba2623128fc6f5a7b
Blink, WebKit, and Edge already support these, and they're in the spec.
Tests submitted to wpt upstream.
MozReview-Commit-ID: 5NFBeClNN7y
--HG--
extra : rebase_source : ea073639904e1ae9449990827ad32626aa6267d9
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 455e252e85c14b4ca841f02794bf0d33133ef10a
Tests for page timeout durations have to use an HTTPD handler that delays
or slows down document load. Otherwise there a risk that the timeout error
is not returned before the document finishes loading.
MozReview-Commit-ID: HGGcXfCuaSH
--HG--
extra : rebase_source : c79b01ca4e56e21877c6fe94309b7b0424d9b552
In the case when the trigger callback inside navigate() uses a generator,
the code has to be synchronized and needs to wait until the contained
command has been completed.
MozReview-Commit-ID: 8qKUMvH7HpS
--HG--
extra : rebase_source : 19a87058d62088701914ab2a468ddffaecec1fe2
In the case of switching to an in-process frame, the checkLoad timer
is setup which waits for the frame's content to finish loading.
But the command doesn't actually wait for those events and calls
sendResponse() immediately. This causes a race condition for the
following commands.
MozReview-Commit-ID: 6vuQ7paQ55K
--HG--
extra : rebase_source : ceb590f435d84ead4eba2e718e1ebaa01900d33f
This uses XPCOM to replace the default process selector with one that always
asks for a new process and then put the old one back again. This comes with a
test to prove that it works.
MozReview-Commit-ID: Bq6KP4VzP7W
--HG--
extra : rebase_source : 1ea86df2e2443be38cfae4e5f8c1336bf742157c
Blake Kaplan
Henrik Skupin
David Burns
Justin Wood
Carsten "Tomcat" Book
Armen Zambrano G.
Dão Gottwald
Honza Bambas
Sebastian Hengst
Wander Lairson Costa
Iris Hsiao
Wes Kocher
Nick Alexander
Michal Novotny
André Bargull
Andrea Marchesini
Andrew Swan
Andreas Tolfsen
Julian Descottes
Gregory Szorc
Jessica Jong
Mantaroh Yoshinaga
Ben Hearsum
Jeremy Chen
Greg Mierzwinski
Joel Maher
Aryeh Gregor
Ben Kelly
Shing Lyu
Dragana Damjanovic
Alexandre Poirot
Chris Pearce
Jared Wein
Phil Ringnalda
Mike Conley
Emilio Cobos Álvarez
Chris Manchester
Andrew McCreight
Xidorn Quan
Cameron McCormack
Olli Pettay
Aki Sasaki