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
Because of bug 1338651, we need to stick to BBB macosx64 builds for now.
MozReview-Commit-ID: AwQc5r6ikUN
--HG--
extra : rebase_source : d5ee1605bf5ec70223e7676bd2d2fd760841d59a
This includes stroke-{opacity, miterlimit, stroke-dasharray}.
In this patch, we added opacityType to enabled stroke-opacity's
animation tests. With the newly added opacityType, we should be
able to test other opacity like properties as well.
Re-use existing positiveNumberType for stroke-miterlimit.
As for stroke-dasharray, we add a separated type specifically for it. Note
that we haven't supported unitless length in servo and stylo yet, so I didn't
add tests for length. We should add some once we support unitless length
in servo and stylo.
MozReview-Commit-ID: HIUSyvKA2G3
--HG--
extra : rebase_source : 08fdcdbf0895e691cb47dcf54c59dde38071c7dc
Re-raising an HTTPError with a modified reason would require 6 parameters
which we do not have at this point. So re-raise a normal Exception instead.
MozReview-Commit-ID: J9ws4IMDy3g
--HG--
extra : rebase_source : 59af3f6fa28ea4a0057419e340ef011abfcf10a2
The unit tests for the software update class should not rely on
the remote update URL being reachable. Instead a locally served
URL has to be used.
MozReview-Commit-ID: 8WNoEb0PUWz
--HG--
extra : rebase_source : 85900716de5c868efd8f0411e0c577f317d98d25
Some bits taken from a patch by Cameron McCormack. This follows a
change to the DOM spec that has already been implemented by WebKit.
We do no checks for duplicates on initial attribute parsing, only when
the DOMTokenList is accessed. We re-check for duplicates on every
DOMTokenList access, but optimized with a bloom filter, so it should be
fast. It would be possible to add a flag to check if we've already
removed duplicates from the atom list, but it would require the
nsAttrValue to talk to the nsDOMTokenList somehow, and a spare bit would
be needed in nsAttrValue, and it would only help cases where
DOMTokenList is repeatedly accessed without the content attribute being
modified in between (e.g., .length) where the token list is extremely
long.
This patch assumes that no one other than nsDOMTokenList cares if
duplicates are removed from the nsAttrValue's atom array. If anything
does, they will see inconsistent behavior depending on whether
nsDOMTokenList has removed duplicates yet. Since we don't want to
check for duplicates on parse for performance reasons, the correct fix
is to update the code elsewhere to also remove duplicates.
MozReview-Commit-ID: 97KRVhPGwm8
--HG--
extra : rebase_source : 59fc76e26ea2055eb46fa6380c198c7a1e88ca61
Write the allocated port to the marionette.port preference when binding
the TCP socket server to the requested port.
If the socket is bound to port 0, this instructs the system to atomically
allocate a free port in the ephemeral range. Writing the resolved port
to a preference will make it possible to communicate this port number
to the client, removing any chance of a race condition occurring by the
client looking for a free port (binding and releasing) for the server.
MozReview-Commit-ID: JwyG2G4YQmX
--HG--
extra : rebase_source : 98e38660813c0868f3358183825ad08392e62d37
The test doesn't care about the page load status when a timeout error happened
for a back and forward command. It only compares the urlbar for the expected
url, but doesn't actually wait for the required element on the page.
MozReview-Commit-ID: 8w0iP62rlQZ
--HG--
extra : rebase_source : a78d8530dd181084a5f45e6bffeae136a0cabb74
Now that this is a pref that is different in different versions, tests
have to work no matter what the pref's value is. For tests that
actually tested line-breaking-related behavior, I made them test all
three separator values. For tests that tested something else and only
incidentally depend on the default paragraph separator, I set
defaultParagraphSeparator to "div".
MozReview-Commit-ID: 8m7eoFRXpEy
--HG--
extra : rebase_source : dc664e87f7ce4f621aa48639cef6e754793e8ab4
With bug 1344748 landed the default preferences and their handling has been
changed. Builds starting with Firefox 54.0 can handle that, but previous
releases don't enable Marionette at all after a restart under special
conditions (invalidating 'update.status' file before the restart).
To prevent the bustage we have to keep the preference
'marionette.defaultPrefs.enabled' around until the next ESR release
is out.
MozReview-Commit-ID: AB3liJlb6M7
--HG--
extra : amend_source : 35ae31af3c1a44d9ad965dbeb395297a73e86a81
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
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
The primary change here is to increase the number of times a failed
download is retried, when downloading test_packages.json and test zip
files, in hopes of recovering from more temporary service interruptions.
Increases WPT wdspec timeouts to more realistic values. Because wdspec
tests interact with the browser from an OOP program, they require more
time to run. Interactive browser tests are also known for generally
being more expensive to run.
25 seconds for the default timeout and 120 seconds for the long timeout
are values picked out of the air and likely needs to be further refined
in the future. It is however the current belief that this moves us in
the right direction.
Further improvements to this approach may involve letting wdspec tests
define timeouts on a per-file or a per-test function level through the
use of pytest-timeouts, but this is purely speculative at this point.
It is the current recommendation to adjust the number of tests and the
runtime duration of the tests in a file according to these new defaults.
MozReview-Commit-ID: 4I3Xz9G6lzv
--HG--
extra : rebase_source : 5ec7439e736dc9978828e420bd31195e63130fed
Certain test types have a need for other defaults than the
wpttest.DEFAULT_TIMEOUT and wpttest.LONG_TIMEOUT values. This patch
changes wptrunner to define default- and long timeouts on a test type
level. This allows a test type to override the default durations defined
in the abstract Test.default_timeout and Test.long_timeout.
Concrete classes, such as ReftestTest and WdspecTest, may override these
class properties.
MozReview-Commit-ID: IS6df5vuIDC
--HG--
extra : rebase_source : a3f37d4524902f2b0d54e14126b57da327f0ec06
There were three issues here: The first is that the TPS's history module didn't
wait for PlacesUtils.history.remove's promise to resolve.
The second is that the SYNC_WIPE_REMOTE in the previous client would cause a
write to the clients collection, which would cause the next client to get a
"sync:collection_changed" push. This caused a sync of *only* the clients
collection upon reciept, which would prevent TPS from explicitly syncing all
engines.
The third is that TPS wasn't correctly handling the cases where logIn would
trigger a sync, which would cause a failure during the first sync of a session.
This would cause failures on other TPS tests as well.
MozReview-Commit-ID: LpqZ7Kt9fyy
--HG--
extra : rebase_source : f1d3c40e2ef4e09cce4d2ce8ae25f2c86ddfee45
This rolls browser.tabs.animate, browser.fullscreen.animate, and
alerts.disableSlidingEffect into a single pref; if any of these are disabled,
we'll disable the new pref too (toolkit.cosmeticAnimations.enabled). Most
future animations will also be subject to this pref.
MozReview-Commit-ID: 77pLMtERDna
--HG--
extra : rebase_source : 8939e453c2277caa4a90123ae09bb542aaa421ed
Because it tests some Gecko-specific things as well, I'm making two
copies, as advised by bz and jgraham. One is to be submitted upstream,
and a second one has local changes. This means most of the test is run
twice.
This overwrites the preexisting Element-classlist.html test upstream. I
think I took the useful bits out of it (particularly replace() testing),
but there are some things that it had that I didn't think were
necessary, including: things that belong in idlharness; .className
testing; testing .contains() and stringification and hasAttribute() and
such after add/remove/etc. (instead of just testing getAttribute()); CSS
class selector matching.
MozReview-Commit-ID: JxPK7OyVLXa
--HG--
rename : dom/base/test/test_classList.html => testing/web-platform/mozilla/tests/dom/classList.html
extra : rebase_source : 31c63fd709a7385e0ed7f4f4ea960f5ccff6e187
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Content listeners that are using the old IPC dispatching technique can
cause Marionette to hang when errors are thrown but not handled. To
ensure errors are returned to the chrome process, all the code has to
be placed in try/catch blocks.
MozReview-Commit-ID: J6fwnFUURl7
--HG--
extra : rebase_source : ade78c8839e58ccb1e603c8e92cba1938519d2f4
When defaultParagraphSeparator is not "br", and we hit Enter on a line
that is not contained in any block element, we first create a new <div>
(or <p>) wrapper to hold the line's contents. If creating this wrapper
fails for some reason, we go ahead and insert a <br> instead.
In some cases, we would get confused and think we didn't create the
block element when really we did. We would insert a <br>, and
afterwards something would get rid of the empty block element. In a
corner case where the line only consisted of a <br> to start with, this
would result in nothing happening, because the original <br> was removed
when creating the block element, and only one <br> was inserted to
replace it.
The correct fix is to just not get confused!
MozReview-Commit-ID: 1U8KHC71bfw
--HG--
extra : rebase_source : 50640615a3a652c3a74c1aef5412eb82daf8c5fb
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 : 4193a01370e903874aa5da1634bdfe5c2b9fd577
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 : f2a95ba66999ee430f58b7aa9de70742a209defd
The Components.classes constructor should throw an error in both the
mutable and the "default" sandbox.
MozReview-Commit-ID: C40nZNaVWwz
--HG--
extra : rebase_source : ced5ccba9108f2cd0c37cf799e83913bf19afac6
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 : 75b2f87a6c9f1b425607e0a743669b985b8f3072
We were previously missing a test for the arguments variable that is
implicitly exposed to functions.
MozReview-Commit-ID: IC6aJcUsyhd
--HG--
extra : rebase_source : d94cdf0a0f4c74b0bb3240b32ad53da107931183
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 : f9338db8adacbccd82f23a3b7a38194d747e27a1
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 : c7431630d24c42ebfd7ded3cf204c1ef245211d0
To ensure that we correctly restart Firefox for update tests, the restart
button in the about window or the old software update window have to be
clicked.
MozReview-Commit-ID: 7acl1DcA85d
--HG--
extra : rebase_source : 8af6c300ae34befc2c05e801ea4b5901659c1c2a
Puppeteer enforces to use an in_app restart, unless the clean argument is
set to True. But whatever case is present, all passed in arguments have
to be forwarded to Marionette.
MozReview-Commit-ID: ADPRvuXhyXh
--HG--
extra : rebase_source : cfc65ae082664a93abbda35b9d3a09e8af2784f0
To ease the investigation of possible page load issues debug logging
output is added to the page load listener.
MozReview-Commit-ID: 18itxTHtnBf
--HG--
extra : rebase_source : 7d5f64125453e57113aa565ca09b4eb61a14ec9a
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 : 2c4d2a19a006645ecd44e08a28309367bf4f8d32
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 : 42f60ad9864d87601cd528a0f1accffb768ba438
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 : 3bc63d130c370354dab27bf40bbf13ec441bd423
This patch does a few things:
a) Adds the resources location from the .app directory to the read whitelist
b) When it's a non-packaged build, mach run (and various mach tests) set an environment variable for the repo location which we allow reads from.
r=haik,froydnj
MozReview-Commit-ID: KNvAoUs5Ati
--HG--
extra : rebase_source : 81ba8bfee0ca96979cf8e30d75cdd47f06bc10ea
This commit makes sccache dump JSON stats at the end of the build, and then
reads them in `BuildScript.generate_build_stats` and adds them to the
build_metrics we submit to Perfherder. The stats dumping is done in
Makefile.in where we currently dump verbose sccache stats because sccache
doesn't persist stats to disk right now and it will also shut down its server
process after 5 minutes, so when the post-build automation steps take more
than 5 minutes the server shuts down and the stats are lost.
Currently it's collecting:
* Cache hit rate
* Cache write errors
* Non-cacheable requests (compiler invocations that sccache can't cache)
We can always grow this list later.
MozReview-Commit-ID: J9CwU7XB05I
--HG--
extra : rebase_source : 084b09c3b0621330ac331a99b1bca9a15cf833b7
The current setup is confusing, and, I guess, an inheritage from when
the same mozharness configs were used for buildbot and taskcluster jobs.
When mozharness calls tooltool_wrapper.sh, it doesn't set the
TOOLTOOL_CACHE environment variable from its configuration, like it does
for other commands. Instead, it passes the -c flag with the path from
its configuration. Then tooltool_wrapper.sh proceeds with ignoring the
-c flag and using TOOLTOOL_CACHE from the original environment,
inherited from the taskcluster setup script.
The upcoming new wrapper for tooltool in bug 1355731 doesn't keep this
confusing behavior, and respects the cache directory it's given on the
command line.
Now that most jobs run on taskcluster, and few use the same mozharness
config between buildbot and taskcluster, we can now go ahead and change
the TOOLTOOL_CACHE path in the mozharness config to match reality.
The list of files modified was generated from looking at
MOZHARNESS_CONFIG values in the full-task-graph.json file coming from
the Gecko decision task.
--HG--
extra : rebase_source : fe2baee48baffae52f738b4168f862c81370fcef
Those jobs, running on taskcluster, don't have a persistent cache
anyways, so we might as well not pretend setting a tooltool cache does
anything, especially considering the configured directory is not
writeable anyways.
--HG--
extra : rebase_source : a435bce42b4c181a6690a42e068bb2e0e875d5e8
We'd like to ensure that both parallel and serial traversal in Stylo are
tested on automation. Since e10s is the future, we've chosen to force
parallel traversal on during e10s tests, and force serial traversal on
during non-e10s tests.
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
This eliminates a 2 minute timeout seen at the end of Android mochitests
and reftests. Attempts to shutdown the web server were failing because
they were directed at IP 10.0.2.2 -- the loopback address for the
Android emulator.
Screenshots is a system add-on imported from https://github.com/mozilla-services/screenshots/.
This is the initial build system patch for building screenshots. ESLint is ignored since Screenshots currently use their own version (this may change in the future).
MozReview-Commit-ID: 4OEcaduaeWE
We don't currently support H.264 on Android in automation, but we can improve
our test coverage by running the VP8 portion of this test in the meantime.
MozReview-Commit-ID: 3SPCTaqlfMk
--HG--
extra : rebase_source : cae3251f489e45f56b04378074083d6b4fd24666
The devicemanager killProcess() is updated to use force-stop first, then
use kill if force-stop does not work.
Browser test harnesses are updated to check if killProcess() worked, and
warn if it failed.
This is from changeset 249a47720ddcf896a9f07600c429a1b4492b805e from
the version-control-tools repo. It contains a fix to restore
compatibility with Mercurial 3.7, which caused mozharness tests
to fail because that test pins Mercurial 3.7.3 in a requirements
file. This is a bug. But getting a modern robustcheckout deployed
is more important than upgrading that test.
File copied verbatim from changeset e0d30b04dac6bcd36b57c711d9c5b1c280f63390
from the version-control-tools repository.
The updated extension now detects and retries after network failures
where it didn't before. This should cut down on the number of
intermittent failures.
MozReview-Commit-ID: 2bFLcGEARTJ
--HG--
extra : rebase_source : ac43b1925713ce33e1d0d835323efc02c30aed74
Our configs as well as the artifact code are not equipped to do this.
MozReview-Commit-ID: BDkI3Peo8Md
--HG--
extra : rebase_source : 66a68737e080decd0f53c265553eacb1237e3194
Our configs and the artifact machinery aren't equipped to handle this.
MozReview-Commit-ID: 68DYmWEdGnA
--HG--
extra : rebase_source : fa79eeab616412acab773b6d6bd46a58399699dd
The error message returned when unmarshalling the timeout configuration
object with invalid input is misleading, because it checks the typing
of the value before the field name.
This patch changes Marionette to run the type assertion for the value
after each case in the switch statement has been evaluated, ensuring
that the field is valid before asserting its value.
It also adds a few unit tests to verify this behaviour.
Fixes: https://github.com/mozilla/geckodriver/issues/633
MozReview-Commit-ID: LVjTyUacD0s
--HG--
extra : rebase_source : f8a215aedfa5edf8ddbd037cae583ec07626de27
As long as update tests do not support the new simplified update ui
it has to be kept disabled.
MozReview-Commit-ID: 4fC0CYhp7Pc
--HG--
extra : rebase_source : f3558973b0153fe2104f0e612120298d711fc491