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
