Has issues:
- needs dependency injection
- needs to be DRY
- should not load mw.eventLogging when we are not in sample
Due to urgency this will be fixed in another commit.
Change-Id: I0df067a619109a7c945f82c8d33fa2e621217f0b
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/619
The invite animation has been made more prominent and the chevron
is highlighted. this only applies until the user opens the
panel for the first time.
Change-Id: I91d1b9bffaf302890f63b741313aa47cc4beef24
Per the design meeting, we are abandoning this feature for now - there is not enough time to ensure it is of acceptable quality.
This reverts commit 4329d453ec.
Change-Id: I27c113ffecb617d442557163722ea5181ed0b2f4
Just a link to the full-size file for now.
Since the link must be to a PNG/JPEG/GIF (so possibly a thumbnail),
and we want to cap the size, we might need to get the URL from the
API, but we need to open the new window right away to avoid popup
blockers, making this patch quite complicated.
Change-Id: I9ce9d2a2d27b75470eae2806d9f9ce2f95f4dac2
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/588
- Fix JS error on pushState
- Fix blur issue where blur(0px) filter would blur anyway
- Fix wrapper sizing issue where its size would be 0 when measured
Bug: 65225
Change-Id: If9279cd56f55f71f261ec54dda8228194988b9ae
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/597
Do not log metadata-open when panel is already fully open and the
user presses the open key. (Same with close).
Also a completely unrelated code simplification.
Change-Id: I1f26b8669aa496d68b61d9a432430bf0864e8533
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/559
This tries to fix a number of related issues:
* the blurred thumbnail was visible for a split-second sometimes
when switching back to an already-loaded image. (Presumably when
JS was sluggish enough to take more than 10 ms to execute.) We
now check whether the promise is pending before showing a placeholder.
(More generally, a lot of unnecessary logic was executed when paging
through already loaded images, like displaying the placeholder, so
this might make the UI a bit more responsive.)
* the blur could get stuck sometimes - I have seen this a few times,
but have never been able to reproduce it, so I'm only guessing, but
maybe the timing was really unfortunate, and we switched back less
than 10 ms before loading finished. We now remove the blur on every
branch, just to be sure.
* adding a progress handler to a promise might not have any immediate
effect, so when switching to an image which was loading, the progress
bar reacted too late. We now store the progress state per thumbnail
so it is always available immediately.
* the progress would animate from 0 to its actual state whenever we
navigated to the image. The change on paging is now instant; the
progress bar only animates when we are looking at it.
* switching quickly back and forthe between a loaded and a loading
image resulted in the loading image becoming unblurred. This seems
fixed now, I'm not sure why. Maybe the "skip on non-pending promise"
logic affects it somehow.
Also removes some unused things / renames some things which were
confusing, and makes an unrelated fix in the image provider, which kept
amassing fail handlers.
Change-Id: I580becff246f197ec1bc65e82acd422620e35578
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/489
- this avoids an issue where the arrow wouldn't point to what we
want when near the edge of the screen
- this avoids an RTL issue where the bubble would go outside of
the screen
Bug: 64258
Change-Id: I1cc9683af2743b093a45b19d7142fe7e5e66423f
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/485
The code to replay clicks and clean up the handler was called after
processing each thumbnail, instead of just once at the end.
This might have caused many subtle issues such as clicks on any
but the first image not replaying correctly; more problematically,
of there were no MediaViewer-compatible thumbs, the handler was
never cleaned up and the clicks were never replayed.
Besides fixing that, this commit also adds a try..finally wrapper
so that the click replaying is not broken even if there is an error
in the thumb processing code. This might or might not be a good
idea. The internets say that try..finally without a catch causes
errors in IE8, but only if it is not wrapped in another try..catch,
so we are probably fine. (Adding a catch which just rethrows the
error would be an alternative, but it messes up stack traces.)
Change-Id: I2f645762103274c92c15a0d4b595d18d93b08415
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/497
Bug: 64345
With latest refactorings, the animatin looked like a glitch.
The position of the panel has been adjusted to (a) make the initial
position the same as shown while the progress bar for better continuity,
and (b) make the move more noticeable by increasing the distance the
panel moves.
To test, clear the local storage variable mmv.hasOpenedMetadata
Change-Id: Ie3ed29826fa15bf4c6b38f0fc8bde4bd84563fb9
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
processThumb() is a mess. This change is kept small since we might
want to backport it per the bugzilla comments; I might follow up
with some refactoring in a separate commit.
Bug: 62518
Change-Id: I1f916b88fe1b667c6c7e51c9bdca186d4aa2ef2c
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/338
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
Fullscreen clicks are only about 5-10% of image views, and there
are a lot of complaints about the app being slow, so until the
speed can be improved in other ways, there is no point in
preloading for the fullscreen mode. Unlike the normal preloading,
it is not queued, and it slows down the normal image loading.
Bug: 64135
Change-Id: Ic145c8a1d5c3729f684e2f6c96f7d84869ef4087
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/474
...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
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
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
Errors which were early enough in the life cycle to completely
block the lightbox from displaying were so far invisible to the user.
We display them in a small popup using the core messaging functionality.
Change-Id: Id04fe5d3b54703e24cd216910b15cc8bae786434
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/414
To achieve consistency with the icons in the Media Viewer panel,
the following has been adjusted:
- Colors onf the "share" icon to match the rest of the icons (updated to the new gray values of Agora).
- Size of the Commons icon has been adjusted both in the SVG file and when it is added in the LESS/CSS. Due to the different aspect ratio of this icon, extra spacing has been added to make it visually fit.
Change-Id: Ic14a869ea96ea1a8202c9988f0c5d330ba3e9a70
For download button and size drop-downs, the size labels
have been set to small and normal weight (in the download button,
other rules made it to be bold if no weight was specified).
Change-Id: I7511b307a8459d6e4a01f0b9540528046ad2be8e
This fixes three issues:
* the overlay way multiplied during history navigation, but only
the last one was cleaned up on exit
* the overlay was not cleaned up when loading a #mediaviewer URL
with an invalid file name
* the overlay was not cleaned up when there was an error creating
the viewer object
This is a quick fix, and does not change the fact that
bootstrapping is an unmaintainable mess which should be cleaned up.
Change-Id: I2838e5e709e7c7308b0a5b27eca24a2584d0a01e
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/414
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
Only show the survey button if the user's language matches and the site is
enabled, and log which site we are on.
The corresponding site configuration commit is
Ic07432649906890785769ce5127761e2c84316e2
Change-Id: I575bb286f4289489b80505c901f5a9e7aeecec8b
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/261
* intializeSelection was removed
* selectItem is replaced by chooseItem, sort of
(selectItem does not always update the UI, I think?)
* remove old workaround, bug was fixed upstream
This fixes the download button and unbreaks lots of unittests.
It does not fix the "Loading" text in the embed tab.
Change-Id: Iec7bf9ad5b516001231c7ba46fda962671aaddd8
- error caused by select() called during focus event
- HTMLElement not existing in older IEs
- filter rotation for older IEs causing black background bug in IE9
- IE9 lacking progress would have its progress bar never reach 100% and disappear
- Handle e.which value for clicks on IE < 9
Change-Id: I5727ef3f2a9f9aa77eac930f93320e6ce5964c78
