This will be needed by Erik Zachte for compiling per-file image view data.
Since Media Viewer does preloading, it skews the HTTP request-based
statistics. By marking image requests coming from Media Viewer,
it allows us to remove that bias.
Change-Id: Iac8e7770c1a379691547de4b6d47b7d54467f54d
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/1002
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
Make sure it is easy to debug when one of the promises rejects (and
causes the whole promise chain to fail).
I'm not really happy with this, but still seemed better than adding
the same boilerplate error logging code to each provider one-by-one.
Change-Id: Idd2b638f012ef2ff250e350e2f6a60bb8b81899b
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/268
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
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
* 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
* update paths
* make generate script return failure state on failure
* fix some issues so that it does not actually fail
Change-Id: Idd42e0d8e333c461091079aa1150b1b435e6360c
