This bug fixes this statement in the spec (https://html.spec.whatwg.org/#dom-option):
If selected is true, then set option's selectedness to true; otherwise set its
selectedness to false (even if defaultSelected is true).
And also reset the dirtiness.
This patch also reverts the changes in Bug 927796 and 942648, which was added
because IsSelected() returned inaccurately (called from SelectSomething()).
Verified that the tests added in Bug 927796 and 942648 do pass.
MozReview-Commit-ID: 8PVgvCIHPj4
Chromium doesn't make focused editing host blurred when a Selection API method call moves selection to a non-editable node. Let's follow same behavior for compatibility with both Chromium and Gecko 54.
MozReview-Commit-ID: HXmYX18HVA5
--HG--
extra : rebase_source : 61a380b9f08abc1049d72cc3dd0c4d262f9eaff9
This removes importScript functionality that was used extensively for
B2G testing but is no longer used in tree.
MozReview-Commit-ID: 1O7GWCZPWRZ
--HG--
extra : rebase_source : dc57710690116d9f473271f88f43f298590e895e
The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 5a10a3ebbfe0ce2a801330041f95447c313a9a70
extra : source : 6f0394b523a66dab444b8551deb8f3c6c81d8f31
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 64395c5fdf25deebd60dfbf2cf5df3cbf7ca8abb
extra : amend_source : 0a3f13419c050662680f2bd110d724b3bf991732
extra : source : 8d53be05afc59519c5ce8cfae96d284a972fda71
The browser-chrome self-test files now use the setExpectedFailuresForSelfTest function to specify the exact number of assertion failures that will be triggered. Also, most failures are now intercepted when specifying the "fail-if" property in a "browser.ini" manifest, while previously only those triggered using the "ok" function were intercepted. This allows re-enabling several browser-chome self-tests.
MozReview-Commit-ID: DlDjWaJPfvH
--HG--
extra : rebase_source : d9977dac6ecbd2b28f5697d22ce6edf4e1d4f899
extra : source : 6da58c7bb247d3e879012bea8d848eb68f16e36e
The whitelisting function thisTestLeaksUncaughtRejectionsAndShouldBeFixed was replaced by expectUncaughtRejection, and existing calls did not take effect anymore.
MozReview-Commit-ID: 3uOxkgWYWEz
--HG--
extra : rebase_source : 3a7720091180a770b32b595f8094c0d20170166d
The browser-chrome test suite now detects and reports unhandled rejections of native Promises, in addition to those created by Promise.jsm. The whitelisting mechanism is updated to use primarily the PromiseTestUtils.expectUncaughtRejection function. Tests will fail if a rejection that is not whitelisted occurs, or if a whitelisted rejection does not occur anymore.
MozReview-Commit-ID: 1beGB5GG8Ty
--HG--
extra : rebase_source : 59e5b84cb431f3ca28287d30a3da8fbea1363ec5
The browser-chrome self-test files now use the setExpectedFailuresForSelfTest function to specify the exact number of assertion failures that will be triggered. Also, most failures are now intercepted when specifying the "fail-if" property in a "browser.ini" manifest, while previously only those triggered using the "ok" function were intercepted. This allows re-enabling several browser-chome self-tests.
MozReview-Commit-ID: DlDjWaJPfvH
--HG--
extra : rebase_source : 498914c84ab69dd484fb5487ad9967073c331fd3
All connections to mozqa.com which do not use SSL have to be done
to a unique subdomain. This was requested to lower the amount of
active HTTP endpoints.
MozReview-Commit-ID: JAFjQFhTCxT
--HG--
extra : rebase_source : 7f584f4a3848b122eadd6e25799d43718352a03d
F10, F7 and others activate browser menus in the Linux test environment,
so call preventDefault to stop it.
The default bevahiour interferes with tests running against the upcoming
beta build. Although nightly builds also have this behaviour, it doesn't
appear to intefere with the tests.
MozReview-Commit-ID: 1PiqmtG1SfB
--HG--
extra : rebase_source : 84ed306de9aac4bd25ebfd0ebb1f15e20def55ae
In addition to saving the log level of 'process_output' messages, this will also start passing 'log'
messages through the error lists. This means mozharness will start using 'log' errors when determining
the tbpl_status and worst_log_level.
MozReview-Commit-ID: CZnH6aI1Wo0
--HG--
extra : rebase_source : 28c00105d3fa14d16b637b4275b29e6604f4691d
As of bug 1342503 being fixed, all of our desktop firefox builds have
webrender compiled in by default. Webrender can therefore be enabled at
runtime either by a pref or environment variable on any desktop firefox
build. The old builds that we originally used to stand up webrender are
no longer needed, as the *only* difference between them and the regular
builds are that they build with the pref turned on instead of turned
off. This doesn't warrant keeping around these extra builds, and this
patch removes them along with all the associated goop that was needed to
configure them.
MozReview-Commit-ID: 5wlOWo11fEk
--HG--
extra : rebase_source : 696afdd2d9fb5f7932d0737a7d71c3aa6af0bd64
In addition to saving the log level of 'process_output' messages, this will also start passing 'log'
messages through the error lists. This means mozharness will start using 'log' errors when determining
the tbpl_status and worst_log_level.
MozReview-Commit-ID: CZnH6aI1Wo0
--HG--
extra : rebase_source : 55c74bfa2afdf6d7b510b351ad657ecd615d4347
Add configurations for building and uploading AArch64 Nightly builds, in
tier 1 and without artifact support for now.
As for not denoting AArch64 builds as "api-21", I don't really think we
will split AArch64 the way we split ARMv7 before. Originally, we split
into API 9 and API 11+ because of lots of "constrained" devices that
were stuck with API 9. We made an API 9 APK in order to lower our
footprint on those devices. That probably will not be a problem for
AArch64, because devices with API 21+ and AArch64 support are usually
more than capable for running Fennec. Secondly, it was a big change for
Android going from API 9 to API 11+, so we saved quite a bit of
code/resources when we stripped out API 11+. I don't see such drastic
changes going from API 21 to upcoming versions, so even if we did split,
I don't think it'll get us much benefit.
MozReview-Commit-ID: 7N7Slv1pPgb
This updates geckodriver's cargo lockfile,
testing/geckodriver/Cargo.lock, with the exact crate versions available
under third_party/rust. This will ensure geckodriver is built using the
correct in-tree crate dependencies.
MozReview-Commit-ID: HtPohwW6uN0
--HG--
extra : rebase_source : cdafc425e572494550ce81d6d8c612496fcaab82
geckodriver is the Mozilla implementation of the WebDriver remote
control interface for Gecko, and provides an HTTPD proxy that
translates the WebDriver protocol to Marionette.
Building this as part of the Firefox build will allow us to run
WPT WebDriver tests to verify our implementation of Marionette and
geckodriver. It also makes it less painful to make changes across
projects.
This change will cause the geckodriver program to be built as part
of regular Firefox builds, except on macOS and Android, and when artifact
builds are enabled.
RUST_PROGRAMS in cross-compile environments cause the wrong linker to
be used. When this bug is fixed, we should be able to enable building
of geckodriver on macOS. This work is tracked in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1329737
On Android, we may one to build a binary for the host system to use
(x86_64), instead of an ARM binary for the emulator.
MozReview-Commit-ID: FG5tmPv4iut
--HG--
extra : rebase_source : 091728fd2582458325689fc6e3d8b317428802d8
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 flag can be used to allow gcov for c++ code coverage to run with '--code-coverage' but it prevents 'gcda' artifacts from being uploaded after the tests are done. The 'gcno' upload is allowed with another flag in the code-coverage config called 'MOZ_CODE_COVERAGE'. Removing it's definition will prevent the 'gcno' file from being uploaded.
MozReview-Commit-ID: 1XkH0P4Bh5A
--HG--
extra : rebase_source : 4340e83de39709a7068e469d7f7d6b1e434c9afd
There is no reason for the command to call into the content framescript.
It's only adding overhead and can currently cause hangs if the framescript
gets reloaded.
Instead use the content browser which is always aware of the current URL.
MozReview-Commit-ID: 9Ui7qClFEWJ
--HG--
extra : rebase_source : e428e71ddb66e0152d164f2aebd20efb0593ceec
The underlying code that this method calls from nsIDOMWindowUtils
was removed and has not caused issues in here. This is dead code.
MozReview-Commit-ID: K245et5SmxJ
--HG--
extra : rebase_source : f5345219b9e9ae9299a1884c3424f2d8bfdf3d20
This additionally changes exit() calls with |return VALUE| so
that we are sure to call the destructors and valgrind doesn't complain.
Moreover, this disables the 'new-profile' ping when Firefox is ran
on test profiles.
MozReview-Commit-ID: BlGE9w6yGCL
--HG--
extra : rebase_source : 4149973f832f968a75ec51b245104cb02fd35d4e
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : cd029cdbbcccc1d16f03d63a5f1fdf60be5db4fd
extra : source : a0e257e346ccf3c1db332ec5903241f4eeb9a7ee
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 : be2b8b6da5cf78c6263502a6cb422e2de81c742d
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 : be2b8b6da5cf78c6263502a6cb422e2de81c742d
Several years ago there was a single zip file for all test files. Clients
would only extract the files they needed. Thus, zip was a reasonable
archive format because it allowed direct access to members without
having to decompress the entirety of the stream.
We have since split up that monolithic archive into separate,
domain-specific archives. e.g. 1 archive for mochitests and one
for xpcshell tests. This drastically cut down on network I/O
required on testers because they only fetched archives/data that
was relevant. It also enabled parallel generation of test archives,
we shaved dozens of seconds off builds due to compression being
a long pole.
Despite the architectural changes to test archive management, we
still used zip files. This is not ideal because we no longer access
specific files in test archives and thus don't care about single/partial
member access performance.
This commit implements support for generating tar.gz test archives.
And it switches the web-platform archive to a tar.gz file.
The performance implications for archive generation are significant:
before: 48,321,250 bytes; 6.05s
after: 31,844,267 bytes; 4.57s
The size is reduced because we have a single compression context
so data from 1 file can benefit compression in a subsequent file.
CPU usage is reduced because the compressor has to work less with
1 context than it does with N. While I didn't measure it, decompression
performance should also be improved for the same reasons. And of course
network I/O will be reduced.
mozharness consumers use a generic method for handling unarchiving.
This method automagically handles multiple file extensions. So as long
as downstream consumers aren't hard coding ".zip" this change should
"just work."
MozReview-Commit-ID: LQa5MIHLsms
--HG--
extra : rebase_source : 19ec875917546abc147b234a815e1a64c204b92a
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
The mochitest-chrome harness sends a custom "contentEvent" event from redirect.html
to a listener in browser-test.js. It is possible for redirect.html to be loaded
and send contentEvent before the listener is set up in browser-test.js. In the
absence of a better synchronization strategy, redirect.html now retries the send
after a few seconds. If the first contentEvent was received, the second will be
ignored; if the first contentEvent was not received, the second should avoid an
intermittent harness hang and timeout.
* marionette: make trace logs safe for windows prompt
The symbols "←" and "→" are encodeed as "?" in the Windows command
prompt. To make the logs from this system useful, use ASCII versions
of the arrows.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 60e7a430dc38a9e1921928c0cd996bb5fc00198b
committer: jgraham <james@hoppipolla.co.uk>
IGNORE BAD COMMIT MESSAGES
--HG--
extra : rebase_source : 261d9d9d73b8e2139dc20bec0985352f2897fabe
extra : amend_source : 4f838fad090337c2a49a3987c3a12d3289e4c7d0
Remove the forbiddenURI pref which was removed in bug 1274893 as well
as browser.safebrowsing.enabled which got renamed in bug 1025965.
Set dummy URLs for all of the network endpoints.
MozReview-Commit-ID: Efk2fv6cC3g
--HG--
extra : rebase_source : 9fbb3eb0fa7f002fe24577a8a0870ec4d1b7cf31
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 : 8502233bc79452df4755dea08b04ab6423cf91ed
Step 10 of EME's "Get Supported Capabilities for Audio/Video Type" algorithm
says we can assume default codecs only if a container normatively implies a
specific set of codec and codec constraints. Our code assumes that WebM implies
Vorbis/VP8 and MP4 implies AAC/H.264, but those aren't actually normatively
required by either of these containers' specifications. So we shouldn't assume
these containers imply those codecs.
MozReview-Commit-ID: G9TDOmrjhpp
--HG--
extra : rebase_source : 2f040d76c8cb240359401fe1dc1e3eefa029d77b
Added before_install to handle packages that solve the current 32-bit Linux optimized release issues.
This addition also ensures future changes in dependencies won't cause similar errors.
Defining OS for the i686 target is no longer needed and will break the build if defined.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: c8508c092fd4428a1caa6d8a46a656e940a3ebd1
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : be082b3c0e15f003a33646aa40f03cd348fe43ad
Our linux32-debug build is very slow to startup when running mochitests on aws.
Sometimes we see similar behavior on other linux platforms. Intermittently,
in this environment, startup takes longer than the 120 seconds that marionette
waits, resulting in test failures in bug 1261598. Increasing the marionette
startup timeout to 180 seconds appears to effectively avoid these failures.
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. Also due to the slowness of the browser, the getUrl
command which gets run before the readyState check takes too long. Doing
the latter check first fixes it.
MozReview-Commit-ID: D2je04Euwf0
--HG--
extra : rebase_source : 0708fcc1eb5b7198fa45ab995de404db34b64968
This is a stub to have tests to run when the buildbot jobs are defined.
As a note, talos is now e10s only, so we do not need the non-e10s version.
MozReview-Commit-ID: IKDPwKFoHlm
There are some files that corresponding meta data have not been updated.
MozReview-Commit-ID: 8uJ7jCLhJt2
--HG--
extra : rebase_source : 0288da865013ef1818b8b4c3323d415e2f1da1d1
In some circumstances mozversion's attempt to read the Firefox version
from ini files can fail. This can be, for example, when the "binary"
is actaully a shell script that launches the real Firefox. In that
case it isn't necessarily possible to locate the ini files without
making the user explicitly provide a path. Instead fall back on
running `firefox -version` in this case and extracting the binary from
the returned string.
Fixes: https://github.com/SeleniumHQ/selenium/issues/3884
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 6d1c7f28da90910c05426bbda8a70c42676033fa
committer: Andreas Tolfsen <ato@mozilla.com>
--HG--
extra : rebase_source : 6d058c8c863022280e3b077b5facb2adf23c02b0
geckodriver currently assumes the response from the CloseWindow command
is empty and unmarshals it to Ok(Void).
Starting with Firefox 52, Marionette returns a window handle array to
indicate whether the last window was closed. If this array is empty,
the delete_session field is set to true and the session is ended.
Fixes: https://github.com/mozilla/geckodriver/issues/613
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: b579b41838918460a63b59a4bb7933ecf485b7f5
committer: jgraham <james@hoppipolla.co.uk>
--HG--
extra : rebase_source : 1adac09285338702ae82c6108d7fc233d45c9cf1
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 : 110082013ac76347f1ff77767e407750bb8bd647
extra : intermediate-source : 6a82d640aa274f6532528bd45d9e86ede901f44d
extra : source : ca3dddda32b0274d2ed8d700527b2383da36be2c
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.
I also changed an instance of query_exe('python') to use sys.executable
because that is the desired behavior.
MozReview-Commit-ID: 4xiEkoFwekr
--HG--
extra : rebase_source : 0ded9869cb8d1c905782a0c8583abc51692fa0fb
extra : intermediate-source : 23050ffaf6490bb3d7811d586eb174b3c85fd4d6
extra : source : a7a7eb83f9cbf1e6dda8472af8aa35fda2edff88
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 : 652a27158b3b9dc8d582e3c59d0c5cb910f62802
extra : intermediate-source : 402ef9d842a347123d2ba8acf22679272b330f8c
extra : source : fa3f3b08ec2bd9932e675c979068cdef8a677127
This allows running tests with WebRender enabled, using builds that have WebRender
built-in, but not enabled by default.
MozReview-Commit-ID: HkFgB09J7gT
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 : 0e25f372dcdd0cc6ef571bcee5cba675104cd7a4
extra : source : 5e04c49d2d10ad48b19cddaf28fee845dc6e8629
Prevent confusion amongst users as towards whether v0.16.0 is out.
Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: dccea97b6cc709b4bd93146ea12c7d9b0b356688
--HG--
extra : rebase_source : 19985f1ae4f75089c1ee26e5d896292d82a82b0c
Remove suggested and enhanced tiles along with related campaign, frequency-cap, inadjacency, pings, preferences, strings, styles, tests.
MozReview-Commit-ID: FkjaSpSFQHu
--HG--
extra : rebase_source : 1c58ac542180f0abb290639ec1c61b9edf3d0a51
Right now we retrieve window handles at different locations and as
such those are sometimes numbers but also strings. Given that we have
strict comparisons when checking for the id, checks can fail.
The patch also ensures that both close() and closeChromeWindow()
methods are returning the window ids as string.
MozReview-Commit-ID: ImOLe0Z2OE1
--HG--
extra : rebase_source : fe6e7857def2fde4e8253b1bfef8dd2a7d6bd954
"video.controls = false" will remove the binding of videocontrols which is a xul element.
In vtt.jsm, we need to remember the last show/hide status of videocontrols, then render cues when status changed.
MozReview-Commit-ID: 30rebAuqmxy
--HG--
extra : rebase_source : e011ec0679ab03071e01b91c124c5b72e481a8da
By using the page load strategy each navigation request has to return
when the page load has reached the expected document ready state, or
immediately if a strategy of "none" is set.
This also removes the page load checks when switching frames because
this is not part of the webdriver spec.
MozReview-Commit-ID: 3KbsDvzEG6c
--HG--
extra : rebase_source : 68170235424e181c083febd44fca6bb0c5dfec63
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