This behaviour changed in Ife957374cb0d21446db2067171e68fb726ad8347
and related changes
Bug: T214049
Change-Id: I48df96eedebc6e34d62d1cdb02cddb7a091dae86
These no longer seem to be achieving their original
intention and may even be causing the
flakiness we experience now.
Additional changes:
* Disable some more tests in Firefox job
Bug: T208808
Change-Id: I735ec0ff293cfd7aa60519c080a300bd40dc0abc
Instead check the element is in the DOM before testing its
visibility.
This might help T208808 but it's a stab in the dark.
Change-Id: If7ccf5f2f03073c247de7fa497b3a6e31b570918
If mediawiki.notification has loaded that should be enough to assume
the toast is ready to have its text checked.
Change-Id: Ic546877eae0ea6dd59dbf88bf9267bcd1957f779
It seems trying to test both the steps can cause
false positives. Relaxing these checks seems to make
our Jenkins job happy without breaking the tests themselves
Change-Id: I119111e97f23d2f0dac7cbb0e5b86c1df0562598
Changes:
* Use css rather than class for finding toast
* Correct a test typo
* Add a step to wait until the mediawiki.notification module
has been loaded
Bug: T170890
Change-Id: I86e48e00ebb83772149da7c7f20097b5436a0cf5
Copies approach for the text of the first heading should be
accounting for the fact that the toast can have an empty
message "" at any given time.
Bug: T170890
Change-Id: Iba8a503a2aea30cb46fba27f000843183e9c46f1
A toast autohides within 5 seconds and its display properties are
inherited from #mw-notification-area. This slight tweak waits for
mw-notification-area to be visible before verifying toast and its
contents
Change-Id: I89beaf9d131155e958cc9aae84a9e30ffd8e9e4f
Introduces a new generic
"I should see a toast with message ".*""
step reducing toast steps to two generic ones.
Change-Id: Ic8b91c78f6df088244f15223ee4ed658847a05b5
This moves all browser tests from MobileFrontend to the Minerva repo
in preparation for separating the two.
Note, this means browser tests will exist in both repositories for a
period of time. This is important and necessary to ensure we do not
break anything.
See:
https://lists.wikimedia.org/pipermail/mobile-l/2017-July/010536.html
Bug: T168758
Change-Id: I84ae3ea14191f672cabcd52020e80b0a40a72ce1
