This selector was changed in I9ded45388dbcb511cc4bf56859f54318e3e168d9
but the tests are still looking for the old selector which makes the
following tests fail:
- Reference popup drawer.Opening and closing the reference drawer
- Reference popup drawer.Opening a nested reference
Bug: T222475
Change-Id: I4ab8a21146dfd8204151659ff587e77bcadcaf9d
In anticipation of the changes in
I30aa36a0cb89988d1bad8256e5d3f737380bc0a7 which removes the
.wikibase-editor selector from the TalkSectionAddOverlay textarea, the
browser tests need to be changed to a more accomodating selector.
Instead of finding the textarea from the .wikitext-editor selector, the
tests now look for the textarea in the overlay (there is only one). This
also makes it more in line with its method for finding the input element
(.talk-overlay input) as well.
Bug: T221624
Change-Id: Ifbba23e9aee6f68033efc3279ed737d519a7bf41
Uncover a bug and fix it in the process \o/ - it seems that the
close icon is misplaced between clicking the notifications icon
and loading the contents of the overlay - this confuses the webdriver
as the button is not clickable.
Bug: T219920
Change-Id: Ib4d076fd9b7ea1cd48b6b58940a50560eacd51a0
This migrates the first of the browser tests which had a @login
step from Ruby to Node.js
Bug: T219920
Change-Id: I84e217e2a781aab9eb10e7d873c527d578ec8fd4
Follow up to Iad954405a5ae0608fd5dc90dd5dfa434b3781037
This test now lives in tests/selenium
It should be removed as we don't want to run this test twice.
Change-Id: Idc99ffdf0fedf65d46095a77a0066c5eef95c960
These tests fail as the log_in step seems to be broken in the Ruby
Selenium gem. Disabling these makes it possible to merge code at
the cost of lowering test coverage and risk of regressions.
I'm hoping for help from RelEng to get these restored promptly
Bug: T219920
Change-Id: I8e0883e8988293828801be2769db88ac244cb866
The talk overlay is created inside MobileFrontend, but the
overlay for creating a new talk overlay is here.
The two need to speak to either other - in particularly, the create
talk overlay must invalidate the current talk page before returning
the user to the former.
In preparation for the refactoring changes in MobileFrontend, the
same object is shared and the cache invalidation is moved here since
Minerva creates and manages the PageGateway instance that is given
to the talk overlay.
Additional change:
* Update a selector broken by changes in
I8c34646b7ba13a26facbb69684e65109870d27a1
Bug: T217102
Change-Id: I212ff044c4c608c6ea60a5fda043166cd434ec1f
The top level `nav` CSS selector (combined with the nested element
selectors, i.e. `nav ul li a`) represent a general DOM structure
which is not limited to the navigation menu and can interfere with
other styles.
This replaces the `nav` selectors (which have only been used to select
the main navigation) with a `#mw-mf-page-left` selector instead, since
that represents the main navigation as well.
Change-Id: I047108974fd295f196d9f7150c3721c05ac40c6d
The talk overlay must subscribe to the creation of new topics
so that the list of topics in the talk overlay contains the
newly created topic. It does this by subscribing to the
talk-discussion-added event and forcing a route refresh when that
has completed.
Additional changes to browser tests:
1) QA: CSS selector changed for talk overlay
Since I42fd7b08c4b9d92dee549d06de8a0012ea037d28 the '.add' class
was removed from the talk button. This makes the browser test fail
but is a false positive.
2) One of the browser tests was using the same selector to mean
two different elements - the add discussion button in the talk overlay
is now clearly distinguish from the "add discussion" button that is blue
and appears at the bottom of talk pages
Change-Id: I935b3c5f37baf242c06585ae0e2f13d059b9c324
* The check for whether the page issues code has been loaded should
be run just before clicking the banner. It's in the wrong place.
* Now page issues is live across all wikis, no need for "in beta"
check
* Seledctor can be simplified now no need to worry about beta
Change-Id: Ie24a9d9fc1966ca5db2cd0a6a37c1aa6d719924a
Clicking the page issue banner (which is ready from first paint to
be clicked) will not yield the overlay. The user must wait for the JS
to load. Likely the reason for Minerva browser test failures against
beta cluster.
Change-Id: I06c488ca64dd44ad24368a1d6b47bb2646ad4552
The test is failing in stable. Since page issues is going to production
next week this patch can be reverted as soon as that has happened
Change-Id: Idd8de17883006e3cc5f5615781a54a4072a78087
The 2 selector approach is flawed as the .ambox element matches a
hidden element in the old treatment which is not clickable.
I suspect this change will fix the failing browser test on the beta
cluster. Integration tests will continue to test the new selector
in the mean time.
Change-Id: I44a873b2e89069c4a47a428c528592159520568c
* On commit it needs admin rights which it doesn't have
* On browser tests the toast flakes too much.
Bug: T208808
Change-Id: I1fa93c8f451f3f839030fa7a144b1cb285c4239d
Given the fade in/out animation of the toasts and the instability of
the beta cluster and the round trips to Sauce labs, we're seeing lots
of false positives on our browser test reports
Running these per commit should ensure we see minimal regressions and
get some protection. We'll continue to test other scenarios which do not involve
the toast on beta cluster.
Provided we can rely on green browser tests, we will trust the browser
tests more and they will be more useful than they currently are.
Bug: T208808
Change-Id: Idc601ad462de36f2d6d52fe951194b429e6f824f
We use lots of write operations in Minerva browser tests. On the beta
cluster many of these are redundant, as the page already has the content
required or the page already exists
Limit where we do our creation... the less write operations we make the
more stable we can expect these browser tests to be.
Change-Id: If88b878e14bf4a0424fcf23213653cfc2cf8d87b
* features/search_loggedin.feature
They run on integration and are not super-business-critical.
Given their flakiness and Cirrus's likelihood of being down,
don't run it on beta cluster
* tests/browser/features/language.feature
Tag is superfulous, all scenarios repeat it.
* tests/browser/features/toggling.feature
ocassionally fails on firefox. Limit to Chrome and integration
tests
* tests/browser/features/search.feature
Limit the tests that run against beta cluster to search for
partial text and clicking a search result, since these are
two things we want to check integration well with other extensions.
The rest being testing on the more stable @integration tests
should be more than enough.
Change-Id: Ia2e8d3726212fee30725fdb9167ea38aa41eacbf
The page issues browser test is now compatible with both the old
and new treatments.
For consistency, in integration tests it will be run always in
treatment B since that will be the new way to do this going forward.
The beta cluster will test issue treatment A while it continues to be
the default. So with this we enjoy the best of both worlds.
When we enable page issues, the beta cluster will inherit the config
from production and we can remove the treatment testing for treatment B.
A follow up patch, might add testing for a page issue on talk pages,
which will retain treatment A for completeness if this is deemed useful.
Bug: T206647
Change-Id: I586523e452a6809e310f65a2ed55c6771d1965b6
Toast tests are often failing in Firefox build.
They are also tested and pass more consistently in Chrome
Stable browser tests means real bugs get caught more often
so let's disable this browser test against Firefox for the time
being.
Bug: T208808
Change-Id: I05d77eb53657bb3ea0daaad7906a50db6aab66db
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
The toast tests are flaking quite a bit in Firefox but pass in Chrome.
Having them run in both Firefox and Chrome seems less important than
being able to have better confidence in non-flaking tests so I'm removing.
Bug: T208808
Change-Id: I306518a7f3eb375715f6b9d6d599bf4f711ab6aa
Currently beta cluster tests are failing because of a single test.
The test for whether a "tagline" appears on special pages is outdated. We now
show taglines on all special pages (defaulting to empty)
Let's thus remove it.
Additional changes:
* Rephrase "wikidata description" as "tagline" - we use the tagline to display
things other than wikidata descriptions e.g. the tagline on Special:MobileOptions
Change-Id: Icb66563cb3a5e7043ca41f59c826bd4247d89d52
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
In I06ef42cb1461fde7ca0aa903f174c3b1f39ab154 a button became an
a tag and somehow that got through the Jenkins censors.
With this change Jenkins on Minerva will be happy again
Bug: T207480
Change-Id: I3faedb10e46c3e3e237f5b90d71ffe20606fce6d
All of this would only be used with the configuration setting
`$wgMFEditorOptions['anonymousEditing'] = false;`.
Removed features:
* Call-to-action popup in skins.minerva.editor (note that anonymous
editors still get a CTA from MobileFrontend's EditorOverlay code)
* Pointer towards the edit button shown after registering via the CTA
(entire skins.minerva.newusers module)
Bug: T205382
Change-Id: I66c7035f7a23581811dda87c911dea41d4a8e5da
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0.
Depends-On: I6e763cd6b6763c60d2ad47bf384f739dfb1a07c0
Change-Id: Id1692b50f3f0d282c8aea4c45b63845f418e0970
This reverts commit 6daf19dfb5.
Mobilefrontend change was reverted meaning this test should be
restored here so we continue to have coverage.
Change-Id: I2e8eeacaf01aa61040405501d69f329fe3a9bbd6
This is a MobileFrontend feature, implemented
in ExtMobileFrontend::getUserPageContent().
Having the test for it in the Minerva repo made
it harder to make changes to it. Adding it there
in I7cac24cf64422212196439bf49598ed749d5fafa.
Depends-On I7cac24cf64422212196439bf49598ed749d5fafa
Change-Id: I93e0f195b3cad1ae83ee2ae3b5b4c5f08944882e
Follow up to Id312638d86179e75bc670e72e5943f8c00232bbb
which switched the #content area from a div to a main
HTML element causing this to fail to match.
Test suite will now also run on @integration so that
this kind of issue is not caught too late in the beta
cluster.
Additional changes:
* Merge two similar tests
Bug: T201956
Change-Id: I1d402aaebc40dcca61979aa521cd8e1a1ce274d9
These are currently only being run in the daily build
but not on commits meaning this sneaked through our automated
QA into production causing
https://phabricator.wikimedia.org/T200867
Let's protection against this happening again.
Bug: T200867
Change-Id: I2ad6fab8fafa2125be45c5052add9605a9d8121b
Changes:
* Default skin is not configured so noticed on test runs it's using
Default skin for desktop mode. Given this has no footer and way to
switch to mobile this could be problematic in future.
* Remove empty README
* Drop suggested language integration test - setting up interwiki links currently
happens via InterwikiLoadPrefix hook however this seems to be unreliable. The beta
cluster is a much more reliable place to test language links so let's rely on that
instead.
* Drop unnecessary heading check from "Successful edit" scenario. It's unnecessary
and flakey (presumably given the title doesn't change)
* Rename test scenario and remove a duplicate scenario
Depends-On: I888b3c546f77fa350853a7bf9bfbfbeb8ed6de67
Change-Id: I45792a95df7fd4c3299accbffadfa447baefe0ce
We only need to opt into beta to test the beta indicator displays.
There is no need to do this anywhere else in our browser tests.
For the categories test we will enable the feature flag in test mode
and not run it against the beta cluster.
Bug: T174018
Change-Id: I83b5f24236cef6ddd6fc1882bdfff3618a8bf599
* Drop special.feature - it checks a search box is present on
multiple pages. This dates back to when special pages and normal
pages did not use the same code path.
Bug: T174018
Change-Id: Icf59ff95135af91650f8cdeef79bbaed534165f0
Additional change
* Add it to the list of smoke tests
Depends-On: I731608412eb2ade95abb79ed8240cfec0f06fb98
Bug: T189194
Change-Id: If8a20202365d92766c52091d96633a74d72e480e
The talk page JavaScript progressively enhances an
existing button in the page.
Remove the frontend logic and rely entirely on whether
the button is in the page or not.
Additional change:
* The browser tests incorrectly suggest a user needs
5 edits to be able to use the talk feature. This is not
true. They just need to be logged in. Update that logic.
Bug: T167728
Change-Id: Iacedea30bdd0775b3d785db5b143abafd7a18b39
On the beta cluster, the tests are run using "Selenium user" account.
There is a test which assumes the user's page is blank which is now
failing as a result of this edit:
https://en.m.wikipedia.beta.wmflabs.org/w/index.php?title=User:Selenium_user&oldid=371028
Test is now disabled there but will still run on commits via the
@integration tag.
Additional change:
* Drop the additional @login tag
Change-Id: Ie116caed32883c58edfa2ab3dfa47bbbefdd6f31
These flake too much. We have coverage in @firefox or @integration
so let's remove these test runs from the beta cluster job.
All tests will run somewhere.
Bug: T170890
Change-Id: I269991a22ab5a2b54aed8ad453013bb9be648502
If mediawiki.notification has loaded that should be enough to assume
the toast is ready to have its text checked.
Change-Id: Ic546877eae0ea6dd59dbf88bf9267bcd1957f779
These are failing consistently due to T172835. Let's not run it in the
@chrome job and just rely on the Firefox coverage. We'll keep one test
in @chrome as it runs in integration mode (per commit).
Change-Id: Ic417148574208389b66249b2d98e009beef70fa2
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
