The patch aligns the steps for deserializing the page load strategy with
the webdriver specification.
MozReview-Commit-ID: GnVTnhVQVkG
--HG--
extra : rebase_source : c7796817fa6d0397b4821445dc3bd87853e0e509
[Cherry-picked from wpt]
This introduces two fixtures for creating a multi-test session and a
longlived session. For performance it is important that we don't
ordinarily create a new session for each test, but it's also important
that specific tests are able to create new sessions with arbitary
capabilities.
MozReview-Commit-ID: DNZCgmkrwvn
The 5s timeout was not enough for debug builds. I don't really see a
reason to use something other than the default socket timeout here.
MozReview-Commit-ID: Fm5lgSI3lFb
Since the pref is enabled for Nightly-only for now, have the WPT test force it on so that
it doesn't fail at merge day.
MozReview-Commit-ID: 3MCRRqBZ5CM
--HG--
extra : rebase_source : 74c0ff8edd109a055dcff65f9238ca2f82820536
Since we are running python3 from an embeddable zip installation, a
C runtime environment is required, on Windows. We manipulate the PATH
to pick it up from the firefox installation.
Currently Mozharness creates a Python 2.7 virtualenvironment with all
the packages needed for Mozharness to run plus any applications that
need to execute within it.
For Talos, we now need a second Python virtual environment for
mitmproxy, however, this package is for Python 3 and not
for Python 2 (perhaps it could have worked).
In any case, having the ability to support create Python 3
virtual environments will be handy. Specially since the approach
of creating virtual environments is not by using 'virtualenv /path/to/venv'
but by calling the venv module like 'python3 -m venv /path/to/venv'.
The initial implementation only supports a list of modules.
The following iteration will support requirement files and other
parameters needed for pip and internal pypi hosts.
Originally authored by armenzg.
The log messages of what geckodriver sends and receives from the
Marionette server will now be logged at trace level. This brings parity
to the way protocol chatter is logged in the Marionette server.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 15345b6780dc3ab55b8b69f88e7634d80c912b72
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : dca9860c8e23b94c560afc3d90effa2ae3603830
This effectively filters out all log entries from modules that do not
begin with either "geckodriver" or "webdriver". This is a big hack,
but works well enough for the time being.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: baf5451f402be11df5a41df1fc7893ea8e85cb45
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 9056ddebabb690aa69fb57f7b7918b729a8920f9
https://github.com/jgraham/rust_mozrunner/pull/7 was recently submitted
to make mozrunner not imply starting the Marionette server by passing the
--marionette flag. This patch appends -marionette, with a single dash,
so that it will be accepted on Windows systems.
More discussion around this in
2e0054b90e.
Fixes: https://github.com/mozilla/geckodriver/issues/640
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 7c577c04176c1cc7b5bd45928b3a36bd1818c5ae
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 44dda1287b2da1c8199bce149367ee5483f456e7
Travis at some point changed the default compiler in their images to be
clang. Cross-compiling Rust code with clang is not possible quite yet,
so we force gcc to be used.
Fixes: https://github.com/mozilla/geckodriver/issues/495
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 043806820230f720c253d3d305dc15747d994b05
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 5b3a96f126a2b657e7659450489a99451ea4103b
Add documentation that explains where the fresh profiles are created
and how you can get its path from the returned capabilities object.
Fixes: https://github.com/mozilla/geckodriver/issues/605
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 0ad52a1e8f7a7da44a6cd6ec828af6acf3f6631d
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 6bdb014f2a1ab6f31e7f7bc65c685db026e23b52
* readme: expand usage instructions
Expands the usage instructions section of the README to contain actual,
useful information on how to use geckodriver with Selenium and as a
standalone WebDriver server.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: d322bcfb14e92b805adb05826051b2462f89e32c
committer: David Burns <david.burns@theautomatedtester.co.uk>
--HG--
extra : rebase_source : 9d5ebe506f6321712898d519e5ba2c34e91c743b
Following https://bugzilla.mozilla.org/show_bug.cgi?id=1348782
and https://bugzilla.mozilla.org/show_bug.cgi?id=1354323, the
sendKeysToElement and sendKeysToDialog commands in Marionette accept
only a string `text' field as input.
These patches to Firefox has since been uplifted all the way to Firefox
53. In order to make geckodriver work with newer Firefox versions again,
we need to pass the `text' field. But in order to support older Firefoxen
without the `text' field requirement, we also want to continue to send
`value' as a string array.
Clients must unfortunately send a string `text' field, but it is believed
it is easier to upgrade to the latest Selenium release than to pin the
exact versions of geckodriver and Firefox.
Fixes: https://github.com/mozilla/geckodriver/issues/594
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 41f89d878c805e0d66a15f8b6151dda78173ccff
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 1574a632e591dc121cba77fc58c8026435fbef2b
marionette.logging has been renamed marionette.log.level, but we keep
the former around for backwards compatibility with earlier Firefoxen.
This is similar to change made in 8f19dc4dac63da4153584a2a6974c26be9453ecc
for marionette.port.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 46518d9d8ae20eea00dd1c7fdaa1287f8c036c7e
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : fe4aad6bb2dc74789ba1665463084cf873f30a78
Remove one layer of wrapping inside the `capabilities' field when
geckodriver sends the capabilities to Marionette.
Prior to this patch, geckodriver would send the following JSON Object
to Marionette's newSession command:
{capabilities: {foo: 1, {desiredCapabilities: {foo: 1}}}}
Following this patch, it sends:
{foo: 1, {capabilities: {desiredCapabilities: {foo: 1}}}}
In the future, the idea is to remove the capabilities object altogether
and just send
{foo: 1}
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: c6cf7b9e2bc2d01bb20f9fb995ee29a892644d15
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : efafe8e0f0ad4fe9cb853baade31be58e9a50e52
If a web page gets opened in a new tab or window, there is no way for
the navigate command to check the current page load status. Instead
we have to wait until the correct URL is getting reported.
MozReview-Commit-ID: JQhPXRgh5Ae
--HG--
extra : rebase_source : 9b60d62af5d4cec2c1a693e152510807165755ba
The `remove_exes.py` config left mozharness searching for exes, but we do need
a path to tooltool, since it is not in $PATH.
MozReview-Commit-ID: I9gk8rNOmda
--HG--
extra : rebase_source : 9482321128b5d8da085bd38e088649c88ea6294c
This allows subprocesses to log to a shared stream via a queue, so that we
avoid the overhead of a multiprocessing Lock around all log access, but still
avoid races where two processes try to log simultaneously. It's mostly useful
where one process is responsible for the majority of logging, but some messages
will be generated in child processes.
MozReview-Commit-ID: ABl6cvpb6qI
--HG--
extra : rebase_source : 5c749074c1646c7abb865a71b31b3056137ef398
New test will error until bug 1367993 is fixed.
MozReview-Commit-ID: KgyquX6klE8
--HG--
extra : rebase_source : 648acc98a863ed99f60ad2e5a88076b1676f4247
the durationchange event will be queued during the initialization segment received algorithm.
Only once the init segment has been fully processed will update/updateend be queued.
As such, the updateend event must be fired before being able to call appendBuffer once again.
MozReview-Commit-ID: GYQNOwWZ7DH
--HG--
extra : rebase_source : 2151dc8bd301b19c53b67e59f4f33746da59c7cb
readyState is supposed to be updated during MSE's Initialization Segment Received and Coded Frame Processing algorithm.
Only then would the appendBuffer operation terminates by queueing the update/updateend events.
These tests ensure that loadedmetadata and loadeddata are fired first.
MozReview-Commit-ID: BJ5gISQRA7B
--HG--
extra : rebase_source : 3b4956c360224caa50019a6286f0bc6c7f772f63
The marionette.defaultPrefs.port preference
has been renamed to marionette.port as part of
https://bugzilla.mozilla.org/show_bug.cgi?id=1344748.
We keep the fallback preference around until Firefox 54 becomes stable
for backwards compatibility reasons.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 8f19dc4dac63da4153584a2a6974c26be9453ecc
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : c47f609e17ce7310c48f801bd85c9291dfb4b88a
When a user provides a profile that wnats to override browser.warnOnQuit,
browser.tabs.warnOnClose, or browser.showQuitWarning, we should
allow users to do stupid things. We should not prevent the profile's
preferences from being applied.
dom.ipc.cpows.forbid-unsafe-from-browser is being removed because all
targetted Firefoxen are not using any unsafe CPOWs in Marionette code.
marionette.defaultPrefs.enabled is superfluous for as long as the
--marionette flag is being passed to the Firefox binary.
Remaining relevant prefs from prefs::REQUIRED have been merged into
prefs::DEFAULT.
This is a follow-up to the discussion around
https://github.com/mozilla/geckodriver/pull/423.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 2e0054b90ecf1acbe8b442af54441e3cc746933f
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 0d5230475735d09d5e7220b8d8b7b91308074900
Merges prefs::Default prefs into custom profile unless the custom
profile explicitly sets that preference.
Sets the marionette.defaultPrefs.port preference last so users cannot
accidentally overwrite its value by providing it in capabilities.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 95ef3b49bc3fbeac231be22c19f06b7d14f6959b
committer: Andreas Tolfsen <ato@mozilla.com>
--HG--
extra : rebase_source : 2785f3dffdc222b9c8002e7f0e81f438b249683e
This change makes the tests compile and makes use of the public typedef
webdriver::capabilities::Capabilities, which reduces the need for type
declarations of BTreeMap.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 68ca3639937721a5d8ab4c13b6de57fce669ecc9
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 5239f9bfc26c808a5f11f5a8fe741213b73fa443
In the interests of avoiding the
Aborting on channel error.: file c:/builds/moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 2056
error we have seen frequently reported on geckodriver, this change forces
the Flash plugin to be disabled by default. The Firefox homepage triggers
the plugin container to start, which is causing problems when quitting
Firefox through geckodriver.
Since Flash cannot be interacted with through WebDriver and it is soon
going away from the web, I don't think this is a big sacrifice.
Fixes: https://github.com/mozilla/geckodriver/issues/225
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 6ec30ca4a37ca04b0bfab6faa87fbdb926710a8d
committer: GitHub <noreply@github.com>
--HG--
extra : rebase_source : e104ed9d48d03a3e33da0226f3472eb3ee307e16
JavaScript errors that arise from the Marionette implementation are
currently wrapped as WebDriverErrors. A WebDriverError is encoded with
a "webdriver error" error code, which officially does not exist in the
WebDriver specification.
To distinguish WebDriver errors from programming errors of Marionette,
this changes them to be encoded as UnknownErrors (error code
"unknown error"). This will make stacktraces coming from clients
easier to read, since it is clear that the error is not caught by the
WebDriverError-catchall.
MozReview-Commit-ID: A5HejTOgOp8
--HG--
extra : rebase_source : 7bd4f539954dd11973b2bd16c1bf4f4ea7b4a4d7
For debug builds a delay of 1s is too short. It means that a navigation
command will return when the readyState reaches interactive for an eager
page load strategy. But due to the slowness of the browser, the next
command could already operate on a complete readyState. Delaying the load
of resources is the only possible option.
MozReview-Commit-ID: D2je04Euwf0
--HG--
extra : rebase_source : d74f276d96cd5bd2301f9dac8866f9dadc6e2937
This patch removes the magic number and instead uses the ELEMENT_NODE
constant which exists on all objects of the Node prototype chain.
We already test that obj has a nodeType own property.
MozReview-Commit-ID: If9HIkBjCyN
--HG--
extra : rebase_source : 5b04727b53616c08bf74a4f3acb56c33d827d015
According to a recent change in the WebDriver specification, we need to
return an object's JSON representation iff it exists.
The relevant specification prose change was made in
1ee4c61c11.
This patch causes return values that have a toJSON property that is a
function, to return the value of calling said function.
MozReview-Commit-ID: GpQNE9GpjCH
--HG--
extra : rebase_source : 7192bbd484cbaa4661f2442990082aefcdd1570b
This patch renames element.fromJson and element.toJson to
evaluate.fromJSON and evaluate.toJSON, respectively.
The JSON (de)serialisation code belongs more naturally in the evaluate
module, which did not exist when these functions were written.
MozReview-Commit-ID: FJGbjGD1kZ6
--HG--
extra : rebase_source : b2528f545c8213b06b9116299806d8ab8a875250
Support the alwaysMatch/firstMatch new session command. Move the
capabilities handling into geckodriver as far as possible so that
marionette itself should not be rejecting sessions (as this is
expensive and can only happen after gecko starts). Use mozversion to
provide (currently somewhat hacky) version number matching for the
browserVersion capability.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 6f1e3c192463342a0a49f5f3f0af914ad0e1ae7a
committer: Andreas Tolfsen <ato@mozilla.com>
--HG--
extra : rebase_source : eec91abc5dcab0f35cd758ad1900a5d15988bd0d
If the browser is in fullscreen mode and Set Window Rect is called
we need to exit fullscreen mode and then continue to manipulate the
browser.
As described in https://w3c.github.io/webdriver/webdriver-spec.html#set-window-rect
Step 10
MozReview-Commit-ID: 5ixhGOXVBE4
--HG--
extra : rebase_source : 984fd3f38c45cbbb1eaae35bd6dea17842bbc6a3
The test for getting a CSS value off a chrome element relied on a
hardcoded expectation value. To reduce future maintenance, it is better
to get the computed style value and compare it against what Marionette
returns.
MozReview-Commit-ID: 3FbPHGqNEpK
--HG--
extra : rebase_source : 91c0fe0e387152f4c8de1e21c5bda64108249e36
Adds a new system notification, "remote-active", which fires
when the Marionette remote protocol becomes active.
MozReview-Commit-ID: 3Parr82Ch6I
--HG--
extra : rebase_source : 08e2388a067b1decdd6fb62ebef97798d4227faf
This adds a minimal XPCOM interface to access Marionette as a service.
All it does for now is to expose whether the Marionette server is
running, which will report true when the TCP listener socket is open and
false otherwise.
This will be used in browser/base/content/browser.js to determine
whether or not to add a visual UX cue on newly started <xul:browser>s.
MozReview-Commit-ID: 4Q9Oy2B9GQ1
--HG--
extra : rebase_source : 350fc1281ff2aa58e8c0ec1566c55f033878e850
The Marionette XPCOM component is currently called
@mozilla.org/marionette;1, but this change namespaces it under
@mozilla.org/remote/marionette;1 to indicate that it is a remote
protocol because not everyone will understand what that the own-name
"Marionette" means.
MozReview-Commit-ID: HwqAghsWA5W
--HG--
extra : rebase_source : 411c79cf201870a486cf5086e42a00a59d210c83
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 : a42662d67f7eeca8bc5870d3c70c086abf582164
The restart unit tests were using the preference browser.startup.page
with its value set to 3. This actually causes sessionrestore to restore
the session during the next startup. Given that there is a race condition
in retrieving window handles (bug 1363368) it's better to use another
default preference which does not trigger this behavior.
MozReview-Commit-ID: 4m7qHxgI504
--HG--
extra : rebase_source : d5e29c0357dfcbe8395681f57000a7a1db769178
Also set <menu>.type's default value as "toolbar" and
remove HTMLButtonElement.menu per HTML spec.
MozReview-Commit-ID: jE6TmmvWa5
--HG--
extra : rebase_source : f0ded9a69055777b9430aeb91b53fef1a43af8e0
Several mochitests call `assertSnapshots`, which prints a reftest-like output
for use with the reftest analyzer. Update these lines to check failure patterns
before printing, like the regular assertion methods do.
MozReview-Commit-ID: CfChoar7bp8
This is a trivial copy-and-paste error from a few lines above.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 1144fee2461186e9f270e4f4135f166df2c58da1
committer: Andreas Tolfsen <ato@mozilla.com>
--HG--
extra : rebase_source : 807c62892e6dea61b6365c220a2ddef45f2a3bc3
Previously, only the mach resource metrics consulted
perfherder_extra_options. This resulted in many data sets tracking
values for distinct build configurations.
MozReview-Commit-ID: 6t5UaUUvHxT
--HG--
extra : rebase_source : aa832250bbbbe1ffb3e0288f1a9cde5c1399ff10
This patch first adds an argument to the 'do_get_file(...)' function call in 'test_chrome_bookmarks.js' that simply allows the 'chromefiles' folder to be non-existent if it does not exist. The 'CoverageUtils.jsm' file is then modified so that the import of 'osfile.jsm' does not interfere with any tests. So, it is now imported into the script after the test has completed. Two other tests have unwanted behaviour that cause code coverage collection to fail so they are also skipped through this patch.
MozReview-Commit-ID: H42HN1solkh
--HG--
extra : rebase_source : 82706778961cd5d7dee4f66eb691d8ec62bde365
I was going to inline "enable_ccache" into buildbase.py because AFAICT
its value is effectively "if not windows." However, I realized that
all this is doing is dumping ccache stats (something the build system
itself is in a better position to do because it actually knows if
ccache is enabled). Then I realized we don't use ccache directly
any more in automation because we use sccache (or at least that's the
way it should be).
Since there's no need for this ccache code in mozharness, this commit
deletes it. If we want it back, we can add the functionality to
`mach build`.
MozReview-Commit-ID: BrRi1QKe5l3
--HG--
extra : rebase_source : d25a2a159515e560aca3aa21c7a340af4b380859
Previously, mozharness defined a separate action to collect build
metrics. This required the script and/or config to define that
action.
Metrics collection for CI is important. So it should be enabled by
default.
This commit changes the "build" action/method to always call the
metrics collection function after successful build. References to
the "generate-build-stats" action have been removed because it is
redundant.
A side-effect of this change is we may generate build metrics where
we weren't before. This could lead to e.g. duplicate entries in some
Perfherder series. Let's see what breaks ;)
MozReview-Commit-ID: 42UQI5YQTMC
--HG--
extra : rebase_source : 3377c70c833f44ef280a4f81f9ae4a78edcee9cf
Previously, this ran during postflight_build(). The magic postflight_*
methods are called automagically by BaseScript.run_action() and are
only called if the main action method didn't raise. So there should
be no functional difference with this commit.
The reason I changed this is that a subsequent commit will perform
metrics generation from build() and without the build properties
file loaded, at least the OS X 64 opt buildbot build doesn't have
packageFilename defines, which breaks metrics collection.
MozReview-Commit-ID: 54ftuQqGKVi
--HG--
extra : rebase_source : 0aa227592db8fee3c670795b0eee72ffc79862bf
Executing `mach build` through bash.exe was introduced by
5f379c98b962 / bug 1279011. Why, I don't know. Literally every
other invocation of `mach` in mozharness does it directly
or via a Python executable (the latter is necessary on Windows
since `mach` is not a win32 executable).
So, this commit removes bash.exe and executes `mach` via
Python like everyone else.
MozReview-Commit-ID: GFNUVbfHZdq
--HG--
extra : source : ca3dddda32b0274d2ed8d700527b2383da36be2c
extra : histedit_source : 5ed18555204cf1fb60ffbf18e13aac13408b4088
The "python2.7" executable is always defined as sys.executable
in mozharness configs. This abstraction is not necessary.
This commit removes the "python2.7" executable from mozharness configs
and just inlines sys.executable instead.
MozReview-Commit-ID: 4xiEkoFwekr
--HG--
extra : source : a7a7eb83f9cbf1e6dda8472af8aa35fda2edff88
extra : histedit_source : 9075cf31c84937bbc0d05886ee8a5636de1c3c06%2C50f817f93d1436ff46c670b09321523b8c27ab55
Every TaskCluster Windows mozharness config was defining an identical
executable entry for "mach-build." For something that's used exactly once
and is identical, this is not necessary.
This commit moves the login inline into the mozharness Python module.
It assumes that if MOZILLABUILD is defined that it points to a
MozillaBuild path and we should invoke mach through it using the
same mechanism that was defined in the config files.
This commit changes behavior on buildbot because it also defines
MOZILLABUILD but didn't define "mach-build" before. For whatever
reason, TC configs involved bash.exe from their moment of inception
(5f379c98b962 / bug 1279011). This commit restores consistency
between the environments.
I do question whether bash.exe needs to be involved at all. But that's
for another commit.
MozReview-Commit-ID: I5GXHRJ1Eq0
--HG--
extra : source : fa3f3b08ec2bd9932e675c979068cdef8a677127
Executing `mach build` through bash.exe was introduced by
5f379c98b962 / bug 1279011. Why, I don't know. Literally every
other invocation of `mach` in mozharness does it directly
or via a Python executable (the latter is necessary on Windows
since `mach` is not a win32 executable).
So, this commit removes bash.exe and executes `mach` via
Python like everyone else.
MozReview-Commit-ID: GFNUVbfHZdq
--HG--
extra : rebase_source : 5bf1344c6e14a80ab96e3768e4548fde9dba8693
The "python2.7" executable is always defined as sys.executable
in mozharness configs. This abstraction is not necessary.
This commit removes the "python2.7" executable from mozharness configs
and just inlines sys.executable instead.
MozReview-Commit-ID: 4xiEkoFwekr
--HG--
extra : rebase_source : 9562219737e4176e9d0d139fb5a14325ca12ed26
Every TaskCluster Windows mozharness config was defining an identical
executable entry for "mach-build." For something that's used exactly once
and is identical, this is not necessary.
This commit moves the login inline into the mozharness Python module.
It assumes that if MOZILLABUILD is defined that it points to a
MozillaBuild path and we should invoke mach through it using the
same mechanism that was defined in the config files.
This commit changes behavior on buildbot because it also defines
MOZILLABUILD but didn't define "mach-build" before. For whatever
reason, TC configs involved bash.exe from their moment of inception
(5f379c98b962 / bug 1279011). This commit restores consistency
between the environments.
I do question whether bash.exe needs to be involved at all. But that's
for another commit.
MozReview-Commit-ID: I5GXHRJ1Eq0
--HG--
extra : rebase_source : 8675da5a7324dda4bb866e956c5ab6fafe8231e4
`mach build` maintains a persisted database of parsed compiler
warnings. The database should be accurate for both clobber and
incremental builds.
Since we generally want to discourage compiler warnings in the build,
it makes sense to collect the number of compiler warnings as a build
metric.
This commit modifies mozharness to run `mach warnings-list` during
post-build metrics collection and report the number of warnings as
a Perfherder metric.
The alert threshold is set to 1.0, which I think means we should get
a Perfherder alert any time the absolute value of compiler warnings
changes. Of course, this won't catch instances where we fix 1
compiler warning and add a new one, not changing the absolute count.
But it is better than nothing.
MozReview-Commit-ID: CKPCeRGs6ot
--HG--
extra : rebase_source : 0846dfe56fb2c1b7cb9fcff8d2ec84ef2d98cf89
1. Ensure we wait for browser-delayed-startup-finished
2. Parse the profile we're cleaning up from the cleanup phase name instead of
using the selectedProfile.
3. Ensure that bookmark repair doesn't run randomly (this isn't necessary, but
the repair code can make the actual reason for failure much more difficult to
debug, and could probably cause a test to pass when it should not).
4. Add multiprocessCompatible flags so that TPS can still start in nightly (and
because it is).
MozReview-Commit-ID: 98UvRoFOdzv
--HG--
extra : rebase_source : ff1f199eafdcc569cfdf9cb373ee4d059b37ec35
Asynchronous logging through slog has the downside that its buffer does
not flush on flushing the system's stderr.
Using synchronous logging should not have any notable performance
downsides for geckodriver.
Fixes#401.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: fdc2804ef05e450cd93d0939809c9e2b46645547
committer: David Burns <david.burns@theautomatedtester.co.uk>
--HG--
extra : rebase_source : d810813995fb0b8bf9842b4bfc7e0ed74cc023df
Windows XP support will be dropped with Firefox 53 and as
https://github.com/mozilla/geckodriver/issues/392 made clear, the
ktmw32.dll (Kernel Transaction Management system) which geckodriver
relies on is only available in Windows Vista onwards.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 61284e0df7b7309530118cd09d3a57fa26c04d1a
--HG--
extra : rebase_source : b9077b408b1384a5b0fd2c5428883ea8357d1d03
* Add Contributing documentation
When Pull requests and issues are opened, Github automatically links to
the contributing file so that people are aware of it. This hopefully
means that contributors will follow some of the rules.
* fixup! Add Contributing documentation
* fixup! fixup! Add Contributing documentation
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: bbdca678e17671ad3d5a49b7b3f869f536731e22
committer: GitHub <noreply@github.com>
--HG--
extra : rebase_source : e0ca0c9001286e4f27259023eee64d904caca06e
We have a few places that we have scheduled talos tests as part of a sendchange, but have since disbled those tests (android, linux32), or replaced with taskcluster (linux64, macosx). This was discovered when artifact builds were scheduling all talos tests in duplicate for osx.
MozReview-Commit-ID: 6Ze4Ic0GQrY
clap 2.14 introduced aliased arguments, which means we can remove the
workaround using a hidden argument.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 5e93a93224ee00a6624f8c3cb32bb17546da9b56
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 028e314aba6e67db1343467b0b348c356412718f
Template asking for OS, browser version and expected results. Also
added a warning that if information is missing that we will close
the issue until it has been added.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: c447ca025fd635df97d3ef1bdef61dd70b546360
committer: Andreas Tolfsen <ato@mozilla.com>
--HG--
extra : rebase_source : d6689fa33c9bc108361ec8909c03e25998073500
There is a race condition for all navigation tests inside the setUp
method of the BaseNavigationTestCase class. The assert for history
items can already happen if the page hasn't been fully loaded yet.
As such a failure is thrown. To fix this we have to wait for the
page being loaded.
MozReview-Commit-ID: 9LbArVT9WqA
--HG--
extra : rebase_source : 0c64798893b64f66f39e7aca16db9b4423d78047
This implements the Full Screen method described in the WebDriver specification
(http://w3c.github.io/webdriver/webdriver-spec.html#fullscreen-window) as well as
tests for it.
MozReview-Commit-ID: GKec7GNE6rm
--HG--
extra : rebase_source : 92d427b40d6aeb760783e67d4796a56bb0dbc6cb
In cases when the navigation trigger function returns too late and the
beforeunload event has already been fired, the page load currently gets
canceled. This happens because the page unload timer hasn't been set at
this time and the unbeforeunload handler doesn't extend its time.
With this patch a flag is used which indicates if an beforeunload
event already occurred, so when the pageunload timer notifies the page
listener the unload timer can be extended to 5s as expected.
MozReview-Commit-ID: FKK0oGEWijU
--HG--
extra : rebase_source : bf4342cfb439eb85cb87cad922054953e5cb97f3
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 : 4d22d07c6ccfb42718c65fd80cd8a0e20d02f72c
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
This change allows a script to have mitmproxy set up support.
This will make a Firefox installation to import the cert from the mitmproxy
and selecting it as a proxy.
MozReview-Commit-ID: FweyOCzWyN9
--HG--
extra : rebase_source : 268cd3700ce826bb9c1381f87a0b42f6c1ad3c7a
Autoconfig files allow modify a Firefox installation with Javascript code.
This change has the basic functionality without actually modifying Firefox
in any manner.
MozReview-Commit-ID: DDGnlYJb7iE
--HG--
extra : rebase_source : 94fa4a340fb000063f9951790f8ec7c2eefb746b
Henrik Skupin
James Graham
Maja Frydrychowicz
Ryan VanderMeulen
Shawn Huang
Carsten "Tomcat" Book
Matthew Noorenberghe
Geoff Brown
Andreas Tolfsen
Jason Juang
btian
Ho-Pang Hsu
Dustin J. Mitchell
Jean-Yves Avenard
Marc Fisher
Andrew McCreight
Sebastian Hengst
Raajit Raj
Ondřej Machulda
Wes Kocher
AutomatedTester
Thom Chiovoloni
kirhgoph
David Burns
CuriousLearner
Blake Kaplan
Phil Ringnalda
J. Ryan Stinnett
Mantaroh Yoshinaga
Boris Zbarsky
Brian Birtles
Kershaw Chang
Honza Bambas
Xidorn Quan
Eric Garrido
Florian Quèze
Boris Chiou
Gregory Szorc
Greg Mierzwinski
Dão Gottwald
thc202
Edgar Chen
Mike Hommey
Joel Maher
Wander Lairson Costa
Iris Hsiao
Ben Hearsum
Justin Wood
Armen Zambrano G.
Nick Alexander
Michal Novotny
André Bargull
Andrea Marchesini
Andrew Swan
Julian Descottes
Jessica Jong
Jeremy Chen
Aryeh Gregor
Ben Kelly
Shing Lyu
Dragana Damjanovic
Alexandre Poirot
Chris Pearce
Jared Wein
Mike Conley
Emilio Cobos Álvarez
Chris Manchester
Cameron McCormack
Olli Pettay
Aki Sasaki