Solves the bug, and makes the code slightly cleaner, but it
still does not inspire confidence (e.g. use of viewer flags
by a bunch of callbacks that can run for a background image).
Also, the tests seem underspecified.
I'll follow up with some more refactoring.
Change-Id: I2557abcec173691ffce21185bf1a939f1644ba8c
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/489
Cache API responses, both on Varnish and in the user's browser.
The imageinfo request is not cached, since that would make it very
hard to test metadata template edits. Everything else is cached for
one day.
Change-Id: I9149cf40d4448a424073eefd1eb442c70c977687
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/435
Not convinced this is a good thing (file description page still
opens in same window so it is somewhat inconsistent) but suddenly
leaving the lightbox to show the deed feels like a very unintuitive
behavior to me.
Change-Id: I2cca3e4241fd1bb2848c11cf425aa75aad8c4a30
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/472
Works, but awkward - the extension name changes a little later than the button
text itself. This is hard to avoid since we don't know beforehand
what the thumbnail type is - we have to wait for the API request.
(We can't do thumbnail URL guessing here since we cannot catch the 404 error.)
In general the whole API handling here is not so good, with a separate API
request going out when we should just get all size options in a single request,
when the user opens the reuse panel.
Change-Id: I502b7cb4e99d8af348d7d1967eb8343ec0f926fe
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/471
...since there probably still is one, and our failure to parse it
just makes it more important that we direct the user to the file
page.
Change-Id: Id31f95021f059ccf4bf9893b1146f3807dcabdcb
Given a sample thumbnail URL and the original width/height
this provider tries to guess the thumbnail url for a given
size.
Change-Id: I2966b60978ab763864475851d8a79370bd422dc4
* 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
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 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
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
The way categories were handled made it impossible to add anything
after them (they always ended up as the last child of the parent
container). This commit fixes that, and also moves the repo link
behind them (as required by #270).
Change-Id: I7c561c43897054e60028bd524d8ad5ea85f39e36
