- rearrange DOM structure of above-fold part of the metadata panel:
- rename .mw-mmv-controls to .mw-mmv-above-fold
- the above-fold part is a single positioned div now, with height
explitcitly set
- less LESS gymnastics, above-fold height is a single variable
- add paddings to the p elements instead of the containers
- make all title elements align to baseline (except the logo which
would look horrible)
- discard some CSS which was superfluous
- overspecified sizes/positions
- some top/bottoms for staticly positioned elements
- get rid of the .mw-mmv-drag-affordance div, since a full-width bar
wouldn't really make sense on the bottom of the above-fold section
- flip the chevron and place it to the bottom of the above-fold part;
add colors etc. per spec
- fix stripe button horizontal spacing
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/706
Change-Id: Ic37b4150288055c3fae8d22919ed7b1249db1f09
Several people complained that "Learn more on Wikimedia Commons"
is not clear: it can be interpreted as a link to the Commons
main page, the text does not suggest that the link will be related
to this specific file. The new wording tries to address this.
Change-Id: Ia605cc30c4ca57598f7cebdde60061800a10b6e7
Instead of setting the parent's height as max height of the
<img> element, find the first parent which has a non-automatic
height (that would be .mw-mmv-image-wrapper).
With the old structure, the height of the parent element could
be determined by the height of the image, which would then be
written back into the max-height of the image, messing up the
aspect ratio. I did not see this in the wild, but it was easy
to reproduce by changing the timing of the resize handler (in
particular, I tried to call the resize handler before loading
the new resolution, to make the UI more responsive, and ran
into this problem). This cannot happen anymore now.
This also fix a bug on some browsers (IE 10, maybe iOS Safari)
where the size of the image could be slightly larger than the
available space, and the bottom of the image was obscured by
the metadata panel. I am still not sure how exactly that
happened, but it was related to the <img> parents with automatic
heights having incorrect height. After making sure the <img>
has a max-height derived from an element with non-automatic
height, I cannot reproduce the bug on IE 10 anymore.
Change-Id: I193aefc42e6d6072717643659a9e4c0c8b7c7e93
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/698
Bug: 66244
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
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
http://foo.com/bar was making a request to some random server
responding with HTTP 500 Internal Server Error.
Change-Id: I17f2e0908b849455db5ab1790b15c2344337c24b
jQuery 1.9 changes how $.focus() calls are handled: instead of
directly calling the handlers, it just invokes the DOM element's
focus(), and leaves it to the browser's event handling to trigger
them. This can fail for several reasons (e.g. element is not
attached to document, element is already focused, browser bugs such
as http://bugs.jquery.com/ticket/13363 ), so we are using
triggerHandler('focus') instead, which calls the handlers directly
without simulating actual browser events. Since these are unit
tests verifying event handler attach/unattach behavior, not
acceptance tests verifying actual event handling behavior, that
should be okay.
Change-Id: I65ecda28ace4f380ad33d6212e12069e18001232
- 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
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
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
* 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
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
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
Also make sure that the reuse dialog is positioned right, no
matter where its button is.
Also fixes some minor documentation problem with mw.mmv.ui.canvas
which I noticed in the process.
Change-Id: I86feed07738ebef012e63861ed909f3449b85a53
Also do a bunch of refactoring to:
* keep LESS rules in more sane locations so it is not as hard to get an overview
(most of the metadata panel rules were in mmv.less)
* move mmv.mixins.less up one directory as it is not specific to the UI
* move the SVG icons as all of them were related to the UI
* remove the marging-right hack which was used to keep the title text from
overflowing the button; instead use a float and overflow properties to make
sure text that is too long gets hidden
Change-Id: Icc8ea2e766be67d86ae98c734721b2185bd6c36e
I think this takes care of all the different mutations of
weird states that happen when going from a small to large
images and transitions in the middle, see card/386.
Change-Id: I80527d746614c0bbda7a1084061d292e5d6394a8
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/386
* Following design, use split button to display a pulldown
menu with possible image sizes. The download happens by
sending the special "download" parameter to the server.
* Offer link to preview image in the browser.
Change-Id: Ic9d895fead04c9128186c7376a0bb09f3596335c
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/79
With apologies to anyone who gets a hundred merge conflicts
because of this :)
We had several different prefix styles (mlb-, mw-mlb-, mw-mmv-,
mw-mmv-mmv-, a few unprefixed), which was getting annoying,
and will be confusing to wiki editors who are trying to figure out
where a given style comes from. Such changes are better done before
going live because it breaks all local CSS tweaks on the wiki,
so I am renaming things now (also removing some stuff which wasnt
used anywhere).
Change-Id: I00447a25f0028e234169c6db941bedc99622eb8d
Tests which trigger real animations conflict with tests using
Sinon.js fake timers. As a quick fix, disable animations in those
tests.
Change-Id: I1a5e9fbee853cc29621c6ccf286bd2191241fd2f
Less misleading as we have lots of buttons, and I plan to add a new
button class for the Commons/survey/reuse thing.
Change-Id: I74194e22e9066c58f9c1eba57629458b2b9148b5
Adds site link, license link and long name, replaces internal license name
(we don't have it for most licenses) with short name.
Also fixes some problems in previous changesets that I stumbled on,
renames things to be more consistent/less misleading, and makes
EmbedFileInfo a thin container for existing classes. (That results
in a lot of Demeter's law violations, but it means one less model
to remember, which is a good thing since our property names are
often not very informative (e.g. EmbedFileInfo.url and
Image.url which had completely different meanings))
We always have the site information for embed texts (comes from the repo
API); that part of the tests was pointless, but now that EmbedFileInfo
depends on Repo they became impossible to maintain, hence the
deletion of half the test cases in getThumbnailHtml().
Change-Id: I94e1d0aca14e2a7d5fad983412090add8ad6bfa3
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/369
This takes care of several minor annoyances:
* centralizes all the text processing functions which have been
floating all around the code, and adds proper tests
* filters out invisible elements (sometimes used for metadata)
* avoids merging separate words on HTML->text transformation
* adds caching since doing all this transformations could be
processing-intensive for big chunks of HTML. (This might or
might not be a good idea. I haven't done performance tests, so
this might be premature optimization, and increases memory use.
OTOH these functions are often called in situations where an
immediate UI response is expected (such as selecting a size
from the list) so even small delays would be perceivable.
Bug: 63126
Change-Id: I1ef1e3a33efdfea17612df00da6b629bf39e07aa
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/388
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/369
Last round of fixes and refactorings regarding resize issues
and the Canvas component:
* Consolidate all the width calculation logic inside the Canvas component
* Consolidate image resizing logic in the Canvas component
* Fix size problem with SVG images
* Clean up comments and tests
Change-Id: I0198cc1e3a45f7287b9a7494f73a8f158303f886
Bug: 56454
Mingle: 239
I was going to stage this but better give you the whole enchilada,
it is not that bad, ;-). This is what I am doing:
- Delete things that are not used anymore.
- Componentize image ui element (Canvas).
Bug: 56454
Change-Id: Ib5461639a86d9f8e0a150f6d9543a20058d31e00
Mingle: 239
