Which would cause the image to never appear, even when reopening
Media Viewer. The source of the issue was an uncaught exception in
ThumbnailWidth.
Unfortunately this cannot be covered by E2E because the image
loads too fast in that context, and cucumber/selenium doesn't
have time to catch the placeholder.
Change-Id: I9386f6e857a7974166ddb5eeb7ea731d943eddcf
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/450
* deduplicates URL generating/parsing code
* gets rid of spaces in URLs
* fixes error for file names with / in them (in case they exist;
current MediaWiki seems to disallow such names anyway)
Change-Id: I5aad43f6af1b99523c597c39befcc9db1ecab83a
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/371
Adds a Route class hierarchy for various URL schemes and a Router
class to convert Route classes to and from URLs.
Right now we only have two(-ish) schemes, but in the future we want
to be able to show related images which are not present on the current
page and need shareable URLs for those as well; also we might want
to specify other things in the URL than the current image (the reuse
box being open was one thing discussed); this will be a good framework
to add features like that.
The MainFileRoute class will be used by #416.
Change-Id: I489126a0ada37f91a22a2f48a4e686140a28d162
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/371
The scrolling logic has broken specifically when navigating with the
back button (as opposed to pressing the "close" button). This change
aims to test that scenario.
Change-Id: Ibe31b319c882b7de2a84ae143652144093c50f1c
It turns out that cucumber/selenium will automatically scroll
to the element you want it to click on. As a result we have to do
the same in order for the assertion to be correct when coming back to
the article.
Change-Id: I7d3b6609cfe7cdae9c08a6d723d652ad1a6a7055
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
The download button used a dashed black line to separate options.
It has been changed to a dark green line to better fit the style.
Change-Id: I3224027b69c4c1e5cf2568aed8f4f50ee351c369
The CSS to make the favico twice as big was looking horrible in
Firefox and possibly other browsers. Since we're already
special-casing commons, let's apply a proper SVG instead of the
favico.
Change-Id: Ie32302342eba7aa37bd310c013a9f4d7f9ae187e
Two images contained a white background that was limiting their
use over other background colours.
Change-Id: Ic61e0d223ed927968344b132dbe67952c80bbe28
Make original file width/height part of LightboxImage, and pass it
to the image loading function.
This adds a bit to the big steaming pile of technical debt that is
mmv.js. To be cleaned up later.
Change-Id: I84b8ae75cd1cc3e94c6cf03d174473764cfbf86f
maybeDisplayThumbnail is invoked even when the survey is disabled,
which results in calling functions of a null object.
Change-Id: If7a48349e22069f91af20d8c4bb6a82b7339bd66
Also fixes other issues:
- Some code in mmv.lightboxinterface.js wasn't doing anything
- Canvas buttons were being added to the wrong element
- Several CSS rules were being declared twice, a remnant of the multilightbox days
Change-Id: I6ffa1f6a989964d3863aa9dbeb332c0e59dff2e6
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/409
