mediawiki-extensions-Multim.../tests/browser/features/basic_mmv_navigation.feature
Gilles Dubuc 09374fc9dd Restore article scroll after closing Media Viewer
There used to be a CSS trick with the order we added things to the
page and removed them from it, but it doesn't seem possible anymore
with the new order of execution, with the overlay appearing
immediately and being taken care of inside bootstrap.

The main cause of the bug, however, was the hash reset happening
after the interface was closed.

Doing the scroll restore with jQuery.scrollTo is more future-proof
and testable in QUnit.

Additions were also made to the cucumber E2E test because QUnit
alone wouldn't have caught the hash issue.

This also cleans up custom events a little and reintroduces
pushState on browsers that support the history API.

Change-Id: I63187383b632a2e8793f05380c18db2713856865
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/439
Bug: 63892
2014-04-14 18:04:30 +00:00

27 lines
1.1 KiB
Gherkin

@en.wikipedia.beta.wmflabs.org @login
Feature: Basic Multimedia Viewer navigation
NOTE: This test should be run against '/Lightbox_demo' to work correctly
Original acceptance criteria:
1) Open MMV
2) Check metadata and picture are there
3) Move to next image
4) Check corresponding metadata and picture are there
5) Move to the previous image
6) Check corresponding metadata and picture are there
7) Close MV and make sure we go back to article.
Scenario: Multimedia Viewer (MMV)
Given I am logged in
And I am at a wiki article with at least two embedded pictures
When I click on the first image in the article
Then the image metadata and the image itself should be there
When I click the next arrow
Then the image and metadata of the next image should appear
When I click the previous arrow
Then the image and metadata of the previous image should appear
When I close MMV
Then I should be navigated back to the original wiki article
Then the wiki article should be scrolled to the same position as before opening MMV