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
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
It's important that when we generate the graphs based on
EventLogging data, we have a foolproof way to filter out
local runs that happened during development.
Change-Id: Ifc65d3b4bfb96946a8e8d59d080a6c5ee6552533
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/509
* Remove login since it's not longer needed
* Point to a new smaller test page instead of Lightbox_demo
which should make the tests run much faster
* Tweak selenium scroll workaround which seems to be speed-dependant
Change-Id: I247ae6a5044ecc93b6f3839f1b9ed955b488b5a7
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/475
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
- Runs combinations of cold/warm browser cache and average/large window size
- Sends events with EventLogging that will allow us to generate limn graphs
This should run separately from the other cucumber test we already
have. This one needs different environment variables because it needs
to run against production wikis instead of beta wikipedia
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/378
Change-Id: I53b521ca2759c493aae6fe6e59be8d448e0f15d7
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
