Currently the test doesn't wait for the restore button to become stale,
and as such the call to find_element will return immediately with a
reference to a "h1" element on the error page.
--HG--
extra : rebase_source : 74cc1bfbe929409a56955ec0f5e912256b92c72e
extra : histedit_source : 800c9e2b0df87d655f470f79077a64cfb6776e8a
When Puppeteer opens a new tab using various strategies it relies
on the list of window handles increasing. When performing the
reverse operation of closing a tab, it looks at the length of <tab>
chrome elements in the UI.
This changes the close operation to use the same mechanism as opening
a new tab to determine if the tab has been closed. This seems to
be as reliable as looking at the number of <tab> elements.
As part of a forthcoming window tracking refactoring of Marionette
(https://bugzilla.mozilla.org/show_bug.cgi?id=marionette-window-tracking),
the list of window handles will be made even more reliable: a content
browser will not appear in the window handle list until both the tab
and it's linked content browser has been created and properly initialised.
MozReview-Commit-ID: FY5vGBpn64R
--HG--
extra : rebase_source : 99bad0c88f3b00a46131f1a502e40c61560aa59b
When the Windows OS shuts down, we use a synchronous shutdown mechanism,
this exercises session save and restore in a unique way.
MozReview-Commit-ID: 6sCa3E2wmLY
--HG--
extra : rebase_source : 05014c26faa932165b03f922a63ec9576462bc67
This regressed by bug 1435733 which didn't clear the pref in tearDown of the test, causing
following tests to still have this preference set.
MozReview-Commit-ID: n9conybbQz
--HG--
extra : rebase_source : fe0dfc7c785c18935035c7320a991edc04f3caae
We no longer support legacy extensions with e10s shims, and the only remaining
uses that matter are in-tree test harnesses, which have been fixed. This flag
no longer serves a purpose.
MozReview-Commit-ID: EdCNqF4MttN
--HG--
extra : rebase_source : 0fef334354faa7541628614cb964a29faaa9df41
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