2014-02-04 04:37:22 +00:00
|
|
|
/*
|
|
|
|
* This file is part of the MediaWiki extension MultimediaViewer.
|
|
|
|
*
|
|
|
|
* MultimediaViewer is free software: you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation, either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* MultimediaViewer is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with MultimediaViewer. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
( function ( mw, $ ) {
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Loads an image.
|
2014-02-19 17:38:55 +00:00
|
|
|
* @class mw.mmv.provider.Image
|
2014-11-16 11:31:47 +00:00
|
|
|
* @constructor
|
|
|
|
* @param {string} imageQueryParameter When defined, is a query parameter to add to every image request
|
2014-02-04 04:37:22 +00:00
|
|
|
*/
|
2014-11-16 11:31:47 +00:00
|
|
|
function Image( imageQueryParameter ) {
|
2014-02-13 09:52:40 +00:00
|
|
|
/**
|
2014-11-21 10:07:40 +00:00
|
|
|
* @property {mw.mmv.logging.PerformanceLogger}
|
2014-02-13 09:52:40 +00:00
|
|
|
* @private
|
|
|
|
*/
|
2014-11-21 10:07:40 +00:00
|
|
|
this.performance = new mw.mmv.logging.PerformanceLogger();
|
2014-02-13 09:52:40 +00:00
|
|
|
|
2014-11-16 11:31:47 +00:00
|
|
|
this.imageQueryParameter = imageQueryParameter;
|
|
|
|
|
2014-02-13 09:52:40 +00:00
|
|
|
/**
|
|
|
|
* AJAX call cache.
|
|
|
|
* @property {Object.<string, jQuery.Promise>} cache
|
|
|
|
* @protected
|
|
|
|
*/
|
|
|
|
this.cache = {};
|
2014-02-04 04:37:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2014-11-21 10:07:40 +00:00
|
|
|
* Loads an image and returns it. Includes performance metrics via mw.mmv.logging.PerformanceLogger.
|
Refactor progressbar & blur handling
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
2014-04-25 22:26:34 +00:00
|
|
|
* When the browser supports it, the image is loaded as an AJAX request.
|
2014-02-04 04:37:22 +00:00
|
|
|
* @param {string} url
|
Refactor progressbar & blur handling
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
2014-04-25 22:26:34 +00:00
|
|
|
* @return {jQuery.Promise.<HTMLImageElement>} A promise which resolves to the image object.
|
|
|
|
* When loaded via AJAX, it has progress events, which return an array with the content loaded
|
|
|
|
* so far and with the progress as a floating-point number between 0 and 100.
|
2014-02-04 04:37:22 +00:00
|
|
|
*/
|
2014-02-13 15:48:02 +00:00
|
|
|
Image.prototype.get = function ( url ) {
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
var provider = this,
|
2014-02-13 09:52:40 +00:00
|
|
|
cacheKey = url,
|
2014-11-16 11:31:47 +00:00
|
|
|
extraParam = {},
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
start,
|
2014-11-16 11:31:47 +00:00
|
|
|
rawGet,
|
|
|
|
uri;
|
|
|
|
|
|
|
|
if ( this.imageQueryParameter ) {
|
|
|
|
uri = new mw.Uri( url );
|
|
|
|
extraParam[ this.imageQueryParameter ] = null;
|
|
|
|
url = uri.extend( extraParam ).toString();
|
|
|
|
}
|
2014-02-04 04:37:22 +00:00
|
|
|
|
2014-02-13 09:52:40 +00:00
|
|
|
if ( !this.cache[cacheKey] ) {
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
if ( this.imagePreloadingSupported() ) {
|
|
|
|
rawGet = $.proxy( provider.rawGet, provider, url, true );
|
|
|
|
this.cache[cacheKey] = this.performance.record( 'image', url ).then( rawGet, rawGet );
|
2014-02-13 15:48:02 +00:00
|
|
|
} else {
|
|
|
|
start = $.now();
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
this.cache[cacheKey] = this.rawGet( url );
|
|
|
|
this.cache[cacheKey].always( function () {
|
|
|
|
provider.performance.recordEntry( 'image', $.now() - start, url );
|
|
|
|
} );
|
2014-02-13 15:48:02 +00:00
|
|
|
}
|
Refactor progressbar & blur handling
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
2014-04-25 22:26:34 +00:00
|
|
|
this.cache[cacheKey].fail( function ( error ) {
|
|
|
|
mw.log( provider.constructor.name + ' provider failed to load: ', error );
|
|
|
|
} );
|
2014-02-13 09:52:40 +00:00
|
|
|
}
|
2014-02-04 04:37:22 +00:00
|
|
|
|
Refactor progressbar & blur handling
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
2014-04-25 22:26:34 +00:00
|
|
|
return this.cache[cacheKey];
|
2014-02-04 04:37:22 +00:00
|
|
|
};
|
|
|
|
|
2014-02-13 15:48:02 +00:00
|
|
|
/**
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
* Internal version of get(): no caching, no performance metrics.
|
|
|
|
* @param {string} url
|
|
|
|
* @param {boolean} [cors] if true, use CORS for preloading
|
|
|
|
* @return {jQuery.Promise.<HTMLImageElement>} a promise which resolves to the image object
|
2014-02-13 15:48:02 +00:00
|
|
|
*/
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
Image.prototype.rawGet = function ( url, cors ) {
|
|
|
|
var img = new window.Image(),
|
|
|
|
deferred = $.Deferred();
|
2014-02-13 15:48:02 +00:00
|
|
|
|
2014-03-03 16:17:07 +00:00
|
|
|
// This attribute is necessary in Firefox, which needs it for the image request after
|
|
|
|
// the XHR to hit the cache by being a proper CORS request. In IE11, however,
|
|
|
|
// the presence of that attribute would cause the second image request to miss the cache,
|
|
|
|
// because IE11 adds a no-cache request header to image CORS requests. As a result,
|
|
|
|
// we call needsCrossOrigin to check if the current browser needs to set the attribute
|
|
|
|
// or not in order to avoid loading the image twice.
|
|
|
|
if ( cors && this.needsCrossOrigin() ) {
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
img.crossOrigin = 'anonymous';
|
2014-02-13 15:48:02 +00:00
|
|
|
}
|
|
|
|
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
img.onload = function() {
|
|
|
|
deferred.resolve( img );
|
|
|
|
};
|
|
|
|
img.onerror = function() {
|
|
|
|
deferred.reject( 'could not load image from ' + url );
|
|
|
|
};
|
|
|
|
|
|
|
|
img.src = url;
|
|
|
|
|
|
|
|
return deferred;
|
2014-02-13 15:48:02 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
* Checks whether the current browser supports AJAX preloading of images.
|
2014-02-24 14:34:46 +00:00
|
|
|
* This means that:
|
|
|
|
* - the browser supports CORS requests (large wiki farms usually host images on a
|
|
|
|
* separate domain) and
|
|
|
|
* - either AJAX and normal image loading uses the same cache (when an image is used by a CORS
|
|
|
|
* request, and then normally by setting img.src, it is only loaded once)
|
|
|
|
* - or (as is the case with Firefox) they are cached separately, but that can be changed by
|
|
|
|
* setting the crossOrigin attribute
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
* @return {boolean}
|
2014-02-13 15:48:02 +00:00
|
|
|
*/
|
Use cross-origin img attribute instead of data URI
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/232
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/233
Reverted commits:
8a8d74f01d3dbd6d0c43b7fadc5284d204091761.
63021d0b0e95442cce101f9f92de8f0ff97d5f49.
Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-23 21:46:18 +00:00
|
|
|
Image.prototype.imagePreloadingSupported = function () {
|
2014-02-24 14:34:46 +00:00
|
|
|
// This checks if the browser supports CORS requests in XHRs
|
2014-03-03 16:17:07 +00:00
|
|
|
return window.XMLHttpRequest !== undefined && 'withCredentials' in new XMLHttpRequest();
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Checks whether the current browser needs to set crossOrigin on images to avoid
|
|
|
|
* doing a double load
|
|
|
|
*/
|
|
|
|
Image.prototype.needsCrossOrigin = function () {
|
|
|
|
// This check is essentially "is this browser anything but IE > 10?".
|
|
|
|
// I couldn't find something more topical because IE11 does support the crossOrigin
|
|
|
|
// attribute, just in a counter-productive way compared to all the other browsers
|
|
|
|
// who also support it.
|
|
|
|
return window.MSInputMethodContext === undefined;
|
2014-02-13 15:48:02 +00:00
|
|
|
};
|
|
|
|
|
2014-02-04 04:37:22 +00:00
|
|
|
mw.mmv.provider.Image = Image;
|
|
|
|
}( mediaWiki, jQuery ) );
|