Previously 'up' brought the panel up, and 'down' brought it down,
which might conflict with expectations on scrolling. Up/down keys
now move the metadata panel to the opposite state, no matter what
the current state was.
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/697
Change-Id: I53079d81042afb86354bf44e9dfd662adf1576cb
- open.svg icon added for the "view in browser" feature form the share panel.
- expand.svg icon updated for better icon consistency (spacing also adjusted in the CSS)
Change-Id: Id6176d8f9b4884c9aabde05f1639500d3349f9a7
:not() only works with simple selectors, not composite selectors.
This caused problems for people with customized skins.
Also, this way we only require support for > (wider) instead of
support for :not.
Also fixed footer id and added monobook for good measure.
Bug: 66326
Change-Id: Ibaa0861aff711723dd336eeaa8c12e73110b1c3b
The jQuery update broke onDomEvent('focus') in OOjs UI. This is a
workaround which fixes the issue by binding on the input/textarea
elements directly, instead of their parents.
This introduces the annoying side effect that the metadata panel jumps
a bit when the embed HTML text is selected. (Just for that one, yes.
Weird.) Still better for now than no selection at all.
Change-Id: Ifa4c0600d7b4c0c64487596cbcabd5b4f4a12a19
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/638
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
