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
All Jenkins jobs will fail until this commit is merged:
https://wmf.ci.cloudbees.com/view/mv/
Bug: 61778
Change-Id: I5fb37946bbb15cb1b70045f85aa11ba48ecd2260
* 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
As suggested by Chrismcmahon, I confirmed that there is no need
to fire the onfocus event. We also remove the convenient functions
around this logic.
Change-Id: I00ce04c758e496f76bd5c2a43ad933c952acc5fb
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
The first version of the e2e tests just checked the presence
of some DOM sections. This 2d version actually verifies the
values for most of the components in the viewer.
Change-Id: Iabfd544f05182e86a16cf6bda162bb0abc5cf260
We are using data:URIs to measure performace. This
change broke e2e tests that were trying to match plain urls.
Change-Id: I8220801472cde595dd6651ef2796468eba484071
* 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
