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
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
Cody Tubbs
Wes Kocher
Aryeh Gregor
Geoff Brown
Joel Maher
Andrea Marchesini
Carsten "Tomcat" Book
Matthew Wein
Shawn Huang
Christoph Kerschbaumer
Henrik Skupin
Hiroyuki Ikezoe
Hiroyuki Ikezoe
Simon Fraser
Andreas Tolfsen
jgraham
tiago
Gregory Szorc
Raajit Raj
Kris Maglione
Sebastian Hengst
Ryan VanderMeulen
Alin Selagea
Iris Hsiao
Honza Bambas
Kartikaya Gupta
Jonathan Guillotte-Blouin
Jason Juang
Mihai Tabara
Phil Ringnalda
Dustin J. Mitchell
Ed Lee
bechen
squeaks
Maja Frydrychowicz
Matthew Noorenberghe
btian
Ho-Pang Hsu
Jean-Yves Avenard
Marc Fisher
Andrew McCreight
Ondřej Machulda
AutomatedTester
Thom Chiovoloni
kirhgoph
David Burns
CuriousLearner
Blake Kaplan
J. Ryan Stinnett
Mantaroh Yoshinaga
Boris Zbarsky
Brian Birtles
Kershaw Chang
Xidorn Quan
Eric Garrido
Florian Quèze
Boris Chiou
Greg Mierzwinski
Dão Gottwald
thc202
Edgar Chen