Since gBrowser is going to become a plain JS object instead of a DOM node,
we don't want any callers directly referring to the DOM node to get ahold of it.
MozReview-Commit-ID: KbE5dlTWmS
--HG--
extra : rebase_source : ef4caea778db406205b58b9f007846dabb062978
The title is not a visible element and as such getElementText
will return an empty string. Instead use the h1 tag which has
the same content to get this test passing.
MozReview-Commit-ID: FntduPdn1P9
--HG--
extra : rebase_source : 3a9083a949df3e289a0813a4fa3ff05456088d62
The wrapper puppeteer.platform in Firefox UI test was deemed redundant.
MozReview-Commit-ID: LUocC59bLNF
--HG--
extra : rebase_source : e764ba1d09d3f752e75ec6aed80ca93781c319dc
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
In some cases the registration of the frame script takes longer and as
result the page load events for DOMContentLoaded and pageshow are
missed. With that the current command waits forever and causes a page
load timeout error after 300s.
By checking the readyState of the document before the listeners are
getting attached, we can ensure to return immediately if the document
has already been finished loading.
MozReview-Commit-ID: 17f6jVz7sZZ
--HG--
extra : rebase_source : 1cc27fc9bd4d9b4a39607f8d44692dfc7095b2d7
To support webextensions in Puppeteer the current restartless
extension gets replaced by a webextension. It allow us to test
at least the permission notification. This patch only adds basic
support.
MozReview-Commit-ID: FKq76qcOxKu
--HG--
extra : rebase_source : 1dc81e80c43d3ec61f3ff405fa7807a08ab1d45e
Ensure that we only wait for the providers that are enabled (i.e. have active lists) to avoid waiting forever
and timing out.
In order to check whether or not the google and google4 providers are enabled, we look for lists that start
with "goog" in both the V2 files and the V4 files. We use 'goog' here instead of 'goog-' because there are
both 'goog-xxx-xxx' and 'googpub-xxx-xxx' tables
MozReview-Commit-ID: 72JWZRs3Qxd
--HG--
extra : rebase_source : 93e970ab43c22f41962996f4daf1d4e0a9506923
Bug 1370576 disabled staging of application updates, which is not yet
supported in our firefox-ui update tests. As result there is a hang and
the restart button is never clicked on.
This is just a wallpaper fix and full support might still have to
be integrated if wanted.
MozReview-Commit-ID: 8LF1RKxnMEb
--HG--
extra : rebase_source : 5a268cd891a6577eda163c86fe6ef94fe767fbff
This is needed before we can upgrade to flake8 3.3.0, as that version starts flagging these errors.
These files were modified by running:
autopep8 --select E305 --in-place -r <dir>
on the affected directories. I did it one dir at a time and verified the result after each.
MozReview-Commit-ID: FmlsfiKIbtr
--HG--
extra : rebase_source : 9df32258cadff5d27a0e72113c57f782756c0b18
Instead of 'itemCount' the 'maxResults' property of the autocomplete popup
has to be used, because it doens't get increased similar to 'itemCount' but
stays the same all the time.
Further we cannot do an equal check in the puppeteer unit test but only do
a check for 0 < visible results <= maxResults, to ensure that items are
visible. Using the dot instead, should also give us more and more accurate
results across different locales.
MozReview-Commit-ID: KZEhq87kvx7
--HG--
extra : rebase_source : f429730d3f4a8da28b481b42c916145ae82e6bb5
