Search suggestions create unneccessary network requests and the suggestions
opt-in notification interferes with tests that don't expect it to be there.
So, this patch updates the default settings in Marionette to disable both.
MozReview-Commit-ID: 8X8SYPq19tj
--HG--
extra : rebase_source : cd0fe8f3437340b1266d161e1cad46bcbcd1a6f6
The wrapper puppeteer.platform in Firefox UI test was deemed redundant.
MozReview-Commit-ID: LUocC59bLNF
--HG--
extra : rebase_source : e764ba1d09d3f752e75ec6aed80ca93781c319dc
This switches to using a timeout of 120s * timeout_multplier, which is
twice the current value. The Marionette startup_timout value is
removed because it turns out that's only used when marionette starts
the Firefox instance and therefore is ignored in this case.
MozReview-Commit-ID: 4VA8yB6M1d5
--HG--
extra : rebase_source : ba9d506d4061d49f2a95fbb24e690841fc902c97
The sizemodechange event is not strongly connected to the
visibilitychange event that the WPT minimize_window.py test is now
using to ascertain whether the window has been successfully iconified.
Because Marionette uses the sizemodechange event it is causing
intermittents such as https://bugzil.la/1397007. You can also read a
lengthy summary I did on the problem in https://bugzil.la/1397007#c11.
The fix for the problem is to wait for the visibilitychange DOM
event content.
MozReview-Commit-ID: B6i33Ee5iMC
This makes it possible to subscribe to DOM events in web content, in
order to facilitate fixes for cases such as https://bugzil.la/1397007.
Although the current interface, WebElementEventTarget, is associated with
browser.Context (curBrowser) it is the intention that we in the future
will associate this with representations of the marshaled web element.
This will make it quack and act like an Element's EventTarget, which
has nice parity to it.
The WebElementEventTarget works by passing IPC messages to
a backend service in the content frame script implemented by
ContentEventObserverService. This registers event handlers for specific
DOM events, and relays these events back to the browser-specific message
handler in chrome.
This will enable chrome code to wait for events to occur in content,
like this:
await new Promise(resolve => {
webElement.addEventListener("visibilitychange", resolve, {once: true});
contentBrowser.minimize();
});
MozReview-Commit-ID: B8MMHyG8n04
--HG--
extra : rebase_source : 25ac77fbcfb09435325719ac61614c4a8ce37996
On Windows TaskCluster workers Marionette could be ready within 1s.
As such the currently used timeout is too long, and needs to be
further reduced.
MozReview-Commit-ID: KbLVdpB71cu
--HG--
extra : rebase_source : 2b9139e4b7e2c9d5815e7cc481086ca779385538
Shield experiments interfer with core features of Firefox which can
cause tests run via Marionette or geckodriver to fail. Resetting the
API URL will make sure that no experiments can be downloaded.
MozReview-Commit-ID: HnE49jfnen7
--HG--
extra : rebase_source : 2fa6cf86ddce798eba88a41d227768f149cccc70
Shield experiments interfer with core features of Firefox which can
cause tests run via Marionette or geckodriver to fail. Resetting the
API URL will make sure that no experiments can be downloaded.
MozReview-Commit-ID: HnE49jfnen7
--HG--
extra : rebase_source : 9cec29085032318e9e8467d6d754afe0890ae645
When the binary gets launched we do not immediately kill the process if the
connection to Marionette server cannot be established within the given amount
of seconds. Instead "_handle_socket_failure" is getting called because
the utility method `raise_for_port` inappropriately uses the `@do_process_check`
decorator.
By removing the decorator the initial connection attempt can be handled
differently. As such the process if handled by Marionette will be immediately
killed. Currently we are waiting for the process to quit itself within 120s,
which will actually never happen due to no active session.
Further `start_session` defaults to a timeout of 60s which itself is problematic
for test harnesses using Marionette but controlling the binary themselves. In
those cases timeouts can happen often for slow starting browser processes like
debug builds. Instead this timeout should default to the `startup_timeout` value.
MozReview-Commit-ID: BZvX5KT45mK
--HG--
extra : rebase_source : 875807b75f0575a10dc9de3588237002fa6a5821
Take into account that a weak referenced element might have been destroyed
in the element staleness check.
An error is thrown when the reference object has been destroyed when
getting a weakrefs' pointer. We catch this, but element.isStale does
not take into account that the el argument in this case can be null,
or in this revision of the patch, undefined.
MozReview-Commit-ID: 7sr4YGhAotS
--HG--
extra : rebase_source : 995eeef4ec1b19bf100cb95c4dd343e947b1cf52
When maximizing the window we must restore it from iconified state or
exit fullscreen first. Likewise for minimizing the window, we must
exit fullscreen. For fullscreening the window we need to also restore
the window.
MozReview-Commit-ID: AOQX2cV2C75
--HG--
extra : rebase_source : 53f310cc261a9a411bc46a04dd50a160a930b5af
This tests both that the settings have the desired effect and that switching
between sharing enabled and sharing disabled without a startup cache flush
does not cause any issues.
Tests for user pref changes are currently non-fatal, since they're known not
to work reliably.
MozReview-Commit-ID: 1ZFwyiNf3da
--HG--
extra : rebase_source : c38bd92d2137c90f8c4d202b7009612b45ff4be9
Currently defaults for startup_timeout and socket_timeout are defined
at two different places (Marionette driver and harness). As of now it's
even the case that startup_timeout has different values. While Marionette
driver uses 120s, the harness only uses 60s.
As result all jobs which are based on the Marionette harness fail if
Firefox starts-up slowly like for debug builds.
MozReview-Commit-ID: Dl4sBG1H7NA
--HG--
extra : rebase_source : 959facabebc371beee23b4de345ddd2495913bb7
Currently defaults for startup_timeout and socket_timeout are defined
at two different places (Marionette driver and harness). As of now it's
even the case that startup_timeout has different values. While Marionette
driver uses 120s, the harness only uses 60s.
As result all jobs which are based on the Marionette harness fail if
Firefox starts-up slowly like for debug builds.
MozReview-Commit-ID: Dl4sBG1H7NA
--HG--
extra : rebase_source : 688338b1782deaf08eb01c7c5d4ca01ba03328f5
To allow resetting the default no proxy exclusion entries in
Firefox tests have to pass an empty noProxy list. This should
also be correctly applied.
MozReview-Commit-ID: ABmYdPvoSvx
--HG--
extra : rebase_source : 313fe0a918a4a9bfe5204e5777568ee5f89744d3
If Marionette client cannot connect to the server, the attempts
have to be logged to stderr. This allows us to inspect the reason
why a connection from the client could not be made, and that it
still tries to connect (see bug 1362293).
MozReview-Commit-ID: ElE1M73ums8
--HG--
extra : rebase_source : e64a549e98b0adc4e7ea410f0d2fd500e0d55f87
Currently the listener for addon installs misses a check for the addon id,
to only resolve the promise when it has been called for the expected addon.
This can cause race-conditions if other addons are getting installed at the
same time.
The same applies to uninstall which doesn't wait at all until the operation
has been completed.
MozReview-Commit-ID: 5GsomMoAVZ1
--HG--
extra : rebase_source : a1b43adb2239b0c28cbee1d843f4b6c666a07f0a
To allow geckodriver to temporarily opt-in for using the webdriver
conforming click, a new custom capability has to be created for
Marionette. If not specified the legacy clickElement method will
be used instead.
MozReview-Commit-ID: LuyTjLJXMGL
--HG--
extra : rebase_source : 8e133fb2d9767ea580468013fedff5233fd8eb93
HTML elements' ownerGlobal is a WindowProxy that indirects operations
to the current browsing context. However, for XUL elements this global
is ChromeWindow which gets reset to null when the window is discarded.
For the same reason, since win indirects to the current browsing context's
associated window, we need to test that the element's node document is
not the active document.
Finally test that its shadow-including root is a document.
MozReview-Commit-ID: EYh18P8DbcN
This patch introduces a new error.stack function as a shorthand for
creating stacktraces. It is equivalent to calling
new Error().stack
and removing the first line of the stack. Removing the first line is
needed to make it appear as if the error originated from the caller's
position in the program.
MozReview-Commit-ID: DpSSWU5vPDm
--HG--
extra : rebase_source : 52697e348367b2b7dbeb28a711a9bd1fdef076ec
pprint is currently exposed twice: once on the error namespace and once
separately. We only want to expose it once, and since there are only a
handful "error.pprint" usages left, we can go ahead and make this change.
When we move transition to use "require" in the future, like devtools
does, it will be possible to use both "error.pprint" and "pprint" styles
without export duplication.
MozReview-Commit-ID: CAnPDWn9Vr7
--HG--
extra : rebase_source : 05a05460d710eb96fa7b20cb94477be0282809de
It turns out that Node.isConnected (described in
https://dom.spec.whatwg.org/#dom-node-isconnected) handles an element’s
shadow root, which element.isDisconnected tries to replicate.
element.isDisconnected and element.isStale are both long and error-prone
and can be removed entirely in favour of this web platform API.
The relevant change to the WebDriver specification landed in
32a477b023.
MozReview-Commit-ID: 5Q0gWLvw8KL
--HG--
extra : rebase_source : 773ab302df27cf11be6079f918a48d3730ceb5c1
In the spec the socksProxyVersion key has been renamed to
socksVersion. Marionette has to be adjusted for this change.
MozReview-Commit-ID: Ep3zNZLKxXl
--HG--
extra : rebase_source : f29f45c9d30fa5f208b595f2e90f544ab652c8cc
The WebDriver spec has been changed a while ago in regard of how
proxy capabilities are getting specified. It means that the port
is no longer its own key but an optional suffix for each of the
ftpProxy, httpProxy, sslProxy, and socksProxy keys.
MozReview-Commit-ID: zdYnVZSf09
--HG--
extra : rebase_source : c4928e6170b52a0ee247f50861646ec29a56bd34
This allows .flake8 files to override one another, and fixes a pretty bad known
bug with our flake8 implementation. For example, say we have a .flake8 file at:
/foo/.flake8
Before this patch, if we ran |mach lint foo/bar|, the configuration defined in
that .flake8 file wouldn't get picked up. It would only work if running the
specific directory that contains it, e.g |mach lint foo|.
This change additionally allows multiple .flake8 files to be used. So if
there's one defined at both:
/.flake8
/foo/.flake8
Then running |mach lint foo/bar| will first apply the root .flake8, then the
one under /foo (overriding earlier configuration).
This bug still doesn't make flake8 configuration perfect though. Any directory
containing a .flake8 file still needs to be explicitly listed in the "include"
section of /tools/lint/flake8.yml. Otherwise in the example above, if running
|mach lint /|, it wouldn't be able to find /foo/.flake8. This is a hard problem
and is likely best solved by fixing flake8's upstream configuration handling.
Unfortunately this means we still can't switch from a whitelist to a blacklist.
MozReview-Commit-ID: 3DZAi1QHYYo
--HG--
extra : rebase_source : 51298c5847f6c2792581d9b312c87b70fa716ee1
A fallout from https://bugzil.la/1392346 was that element.isStale called
element.isDisconnected incorrectly by using the old container object.
This was reported in https://bugzil.la/1392854.
Since we in the long term want to get rid of the concept
of window/shadow root containers (in preparation for
https://bugzil.la/marionette-window-tracking), we might as well fix
the fallout by making element.isDisconnected take separate window-
and shadowRoot arguments, like element.isStale.
Fixes: https://bugzil.la/1392854
MozReview-Commit-ID: ELIu8HsZUfK
--HG--
extra : rebase_source : 3f0cc83048d9f069c47c08c0a6d886033c106825
The background thread hang monitor will crash Firefox after 60s if
a shutdown is too slow. Debug builds are slower and as such Marionette
would force kill Firefox right before the hang monitor can kick in.
MozReview-Commit-ID: GGQFPEZ37dg
--HG--
extra : rebase_source : 99223b83c60be1abad1cc23d8a7c9c31a9f39379
