After checking all the code paths (phew !), it seems
this simple change takes care of the resolution issue
that surfaces mainly in iOS devices (see b/60388).
Bug: 60388
Change-Id: I867dd18f782126fb71eb52ec637a2b90b910050d
This is a big change, but should change nothing except the sizes of some
files and where they all are.
There are no more ext.multimediaViewer strings ANYWHERE, so let's keep
it that way. :)
Change-Id: Ic0892f5894700938bfa01f3f9bc8e5ab8276eb72
It seems the problem was iOS specific. In retina displays the devicePixelRatio
turns out to be 2. This was making the images twice as wide. This was introduced
as a way to fix the resolution problem with some Apple devices, I suppose? Since this is not
fixing the problem I am removing it for the moment. Fixing the resolution issue implies
more changes that will be addressed in another iteration.
Bug: 60173
Change-Id: Iaff2aa6ba13ae85f905ab6d1569572881d8b5990
* Move description and caption to both be in the bottom left
* Make empty description grey and italic
* Fix problem where description was sometimes appended twice
* Move description UI stuff into a separate file, and make it more MVCy
* Tests for description UI stuff
* General framework, to an extent, for UI classes
Change-Id: Ibc8c576cd8a41c2e3cf7e13f1b9e093384fb4655
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/120
Also include the description on the right side of the page, but the caption
generally is more relevant and so should have the place of honour.
+tests
Change-Id: I512b3dd99207878233d501135b4dda0d0bd9cdd6
The foreign repo link in the details area will display the favicon
of the foreign repo when available.
Change-Id: Id946a80beeabcd526f16872efaedbdd291444d2d
Mingle: Multimedia card #107
Image information and repo information are now both stored somewhere
else entirely, so we don't need to keep accessing weird API return
values to sort things out. fetchImageInfo now uses those classes to
an extent, and we now cache thumbnail URLs for different sizes.
Change-Id: Ife8293c86683ea914b1a5a60000584b501d92e55
Not when going prev/next.
The saved position feature was probably broken as well if you
happened to press prev/next.
This was my mistake for not noticing that attach() runs on
prev/next.
Bug: 59861
Change-Id: Ic6ff4b15a54178fb5d38640317650f5676293083
This is just a clever way of marking messages as being useful again -
this way I don't need to go through the hassle of deleting old data.
Change-Id: I6a0574eaae063014340484ffd2552f8118abb939
See the conversation on mediawiki.org:
http://ur1.ca/g14jv
We're trying this out as one option in combatting slow thumbnail load
times. It may or may not work very well.
Bug: 56695
Change-Id: If1211fdff87c0782c7355d654415bfd29d63d84a
I guess this got torn out along the way, but I'm pretty sure this is
what I meant to do - initialize the image object with the thumbnail
URL and then replace it later.
+tests for the failure.
Change-Id: I20ef4e87c6b4b6706ad586f2aa5796736895c780
Also fixes a bug where we didn't clear our arrow key listeners, and VE
would sometimes see lightbox loads accidentally.
+tests for .empty()
Bug: 58107
Change-Id: Ica8326891b2da1f94966dbe72c28e878934ca64f
Third try, merged latest changes and added a test.
Run loading test against a wikipedia.org image.
Change-Id: I4e5a137e0f6dbedc45ec2c8393590919e23a26be
Add test to verify that in case of a resize event no image
replacement takes place when api data is empty/undefined.
Change-Id: I2a880ce4b2e6c158763b1473f6a9f751922187b0
These are just smoke tests. I will add more in coming versions of this change.
Consolidated various cases in one tests. Added tests to validate for legit clicks.
Based on Idfbec829399ff6969cd01be3c13a8ed7a66a1fef
Change-Id: I366c7af9a5cf43361d8293183c9da117bc5d4971
