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
Uses promises in the entirety of fetchImageInfo. Also removes the old
fetchRepoInfo method which was unused (basically) anyway.
Change-Id: Ie7f9a27822ecb893b99dbd755c6199769f2e6784
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
fetchImageInfo() was used to load different property sets,
but had a single cache, so sometimes the results with less properties
overwrote the ones with more.
This is a dirty hack to deal with that. I will revisit once we
use promises.
Bug: 59817
Change-Id: I4f375bcc4e6fcfdb3e3fe7a30fc90a8fd44164c3
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
Makes sure that the advanced description is out of view when
the lightbox opens.
Remembers the scrollTop position that was set when the lightbox
opens, in order to restore it when it closes.
Change-Id: I534f7d718528d1e5a4911c68a524eb96cadeae90
Looks drastic at first, but grows on you.
I based this on an extreme, the firefox inner scrollbar.
Which is huge when hovered.
I kind of wish the close button was a bit bigger, though.
Change-Id: I2f47280c4e7c4bff299149de24741e3381f0b5e9
"Hey! Scroll down! Yeah, you!"
Also fixes the previous arrow button, which got disappeared at some point
Bug: 58431
Change-Id: I98676ee921dc1d3b5780046eabec7415c05f8f4f
'No description available' message has been added when description for the
given file is not available.
Bug: 56446
Change-Id: Ie239e5cd0d1b645ed149ea1ecc80197b0e84bc34
targetWidth was switched to even if the image was way smaller than it,
fixed by only changing to it if the image is too big (too-small images
should never be stretched anyway).
Change-Id: I9e3e6a358e53dbed988b730205a8afec1dbf3483
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