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
Quick and dirty fix for a bug that completely breaks the metadata panel.
Should be refactored later (for a ForeignDbRepo, a missing user is
normal, for anything else it should still be treated as an error
condition, although maybe not with a rejection).
Bug: 62019
Change-Id: I433ae2bd1334593d9c5bfe0272ce7207f3fdf723
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/267
- the bar now starts at 5% for a visual indication that
something is going on
- the bar animates (fast) to 100%, instead of
disappearing immediately
- the animation logic has been fixed to avoid seeing
the bar go backwards
- added sanity check in all the callbacks to make sure
that we don't apply any changes to an image we are
not looking at anymore (including progress updates)
Bug: 58055
Change-Id: I765a61c16513e9330a412c5ec96387623ae7dbc7
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/146
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/242
Fades out the bottom of the text and adds a link to replace it
with the full HTML version. Due to the way it is positioned,
the fade + link will be invisible if the text is less then 3 lines.
The implementation is not very polished; since this will be
replaced by some JS-based ellipsis thing, I didn't want to spend
too much time on it.
Change-Id: Ib30e40fe845b85bfcf9557970efb886d28b3e5c7
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/118
Displays a blurred version of the thumbnail
while the actual image loads
Displays a progress bar showing the image load progress
Animates into focus once the actual image is loaded
Change-Id: I2b8bc4691c20ffb5b3f16da9a8b9d6fd1796d784
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/146
Everything is under mw.mmv now.
(Also, I cut down on the number of direct global instance references a bit.)
Change-Id: I88bb3b62b82ce54126dd069b0aab4412d9404719
The old technique doesn't work in Firefox and
doesn't always work in Chrome depending on
when you call it.
https://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/
Also fixes some tests that weren't overloading
the right function and were hitting the real
feature detection check
Change-Id: I0a9d6b5654efb169860ddf7e5e0551efb825920c
* Fixes the bug where the browser hash would get nuked on
foreign anchor clicks
* Moves the hash handling back into the mmv itself
* Adds test coverage for the hash nuking bug
Change-Id: Iea57d0f4b9090f96e622418223d3f774923e8038
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/254
After lots of experimenting with Wireshark and
current Chrome + Firefox on Ubuntu 13.10, this is my
current understanding of the caching when preloading images
with AJAX requests:
* on Chrome, the image request always comes from browser cache
* Firefox makes two separate requests by default
* Firefox with img.crossOrigin = 'anonymous' makes two separate
requests, but the second one is a 304 (does not load the
image twice)
* when the image has already been cached by the browser (but not in
this session), Chrome skips both requests; Firefox skips the AJAX
request, but sends the normal one, and it returns with 304.
"wish I knew this when I started" things:
* the Chrome DevTools has an option to disable cache. When this is
enabled, requests in the same document context still come from
cache (so if I load the page, fire an AJAX request, then without
reloading the page, fire an AJAX request to the same URL, then the
second request will be cached), but an AJAX request - image request
pair is an exception from this.
* when using Ctrl-F5 in Firefox, requests on that page will never hit
the cache (even AJAX request fired after user activity; even if
two identical requests follow each other). When using clear cache
+ normal reload, this is not the case.
* if the image does not have an Allow-Origin header and is loaded
with crossOrigin=true, Firefox will refuse to load it. Chrome will
log an error in the console saying it refused to load it, but will
actually load it.
* Wireshark rocks.
Pushed some tech debt (browser + domain whitelist) into other tickets:
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/232https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d.
63021d0b0e.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
fileUsage tests were applying styles to the fixture element, which
apparently does not get cleaned between tests. This was because
fileUsage.$container had different semantics from element.$container
(widget's own container div vs. parent container div). FileUsage
now inherits from Element to make sure behavior is consistent.
Change-Id: I8fab8bcf084d8b7e480655114506d9848e9d9a49
* more robust method of obtaining URL
* decouple performance logging from providers (mostly)
* ignore fake XHR object which jQuery returns for JSONP requests
* guard for CORS requests - apparently Chrome refuses to return
certain information even with an Allow-Origin: * response header.
* Resource Timing is limited to 150 results, which causes fake
misses in debug mode. There is an API to increase the limit
but it is not implemented in Chrome. I am calling it nevertheless,
maybe IE understands it (it is present in the MSDN docs at least).
This seems to work for AJAX, CORS, JSONP, image AJAX; CORS requests
return 0 for a lot of values, per spec a Timing-Allow-Origin: *
header might help that.
Change-Id: I8353858022f51a7e70774e65513d0fa2554a5064
When the lightbox is opened, or prev/next pressed, preloads the
previous/next N images.
Technical debt introduced:
* initialization is a mess, with the viewer and the interface
randomly setting properties on each other in different phases of
execution. That got in the way and I shuffled things around
until they worked, which is obviously not the way to have a
robust system, but hopefully it will get scrapped soon anyway
in favor of a clean top-down dependency injection.
Change-Id: Idcb5c40de1ac0b3e482decd66e56c4de8ec71b6b
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/155
A simple task queue which can be processed or cancelled.
Will be used to handle preloading in a more robust way.
Change-Id: Ib33f9b2d814a35538f9d4f3691fce5ba5cdc82c1
* moves generic logic into ThumbnailSizeCalculator class
* moves UI-specific logic into interface class
* fixes bug where non-bucketed sizes were served on devices with
non-standard pixel density
* fixes bug where bucketed size was compared to css size instead of screen size
for resizing
Change-Id: I8ba3380b74fcc8fb0a6ecc3f3140627411851ad0
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/196
* userinfo api requests are cached now
* we use jsonp only if we have to (makes gender api calls measurable on WMF wikis)
* all API calls use providers now, provider.Api constructor can be used to
wrap mw.Api with metrics
Does not return a proper model, and gender API calls are not preloaded together
with the rest of the calls. Maybe next time.
Change-Id: I9b3ea73c65eef57e160ac8636d9e45d349150884
