Repo was only used in two locations:
1. StripeButtons.set for `isCommons` - can be replaced by `descriptionUrl.includes('//commons.wikimedia.org/')`
2. EmbedFileFormatter.getSiteLink (unused)
Furthermore:
- Simplify StripeButtons (we only have one button)
- Unwrap info objects consisting of `ImageModel` and `Repo`
- Remove unused EmbedFileFormatter.getSiteLink
- Inline EmbedFileFormatter.getCaption and EmbedFileFormatter.getLinkUrl
- Fix JSDoc type `ImageModel`
Reduces mmv bundle size from 28012 to 27246.
Bug: T77349
Change-Id: Ia4388fe4d5e1d6112a992e826453cd5799a6a4b4
The response of prop=imageinfo is now an array instead of an object.
Therefor it is not needed to interate over the elements anymore.
The array contains exact one element if one title is used in the query.
The function getNormalizedTitle not needed anymore because the
requested title is always the first element of the array.
Change-Id: I7a226d3950615a2152c3f55127b218cac2d21fcc
The MediaViewer and MultimediaViewer* instruments were disabled circa
October 2021 in Ie7dd8739efc.
This patch removes those instruments and any supporting code and data.
Notably, this patch does not remove the mw.mmv.logging.ViewLogger
instrument, which is responsible for logging image views.
Bug: T310890
Change-Id: I97d41be93849b2ae9d1adba6660546ea716657fd
ImageData will now parse for restrictions (this part has not been
implemented in CommonsMetadata yet), and an orange trademark label
will be displayed next to the license label if there is a 'trademarked'
restriction.
Bug: T77717
Change-Id: Ib03f9708d1e4ff0b5befddc2688b274e2c7ce1f7
- Adds attribution variable to Image model
- In mmv.ui.metadataPanel and mmv.EmbedFileFormatter, display
attribution line instead of author and credit when it is set
- Update junit tests for mmv.model.Image and mmv.EmbedFileFormatter
Bug: T67445
Change-Id: Idfe542a1542d28cf8d27c1720ab0bd54324b2f37
This will be needed by Erik Zachte for compiling per-file image view data.
Since Media Viewer does preloading, it skews the HTTP request-based
statistics. By marking image requests coming from Media Viewer,
it allows us to remove that bias.
Change-Id: Iac8e7770c1a379691547de4b6d47b7d54467f54d
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/1002
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
