Commit graph

18 commits

Author SHA1 Message Date
Fomafix ae99be730e Apply coding conventions for JavaScript
Change-Id: I57a8f188eb1152438a8e94235a6f6801e2617c28
2015-01-23 12:48:27 +00:00
Gilles Dubuc 30029b8b78 Track the most recent upload time for performance events
Change-Id: I673f9487deea15dc148452a3a4d6b91563a2c417
Bug: T76035
2014-12-03 16:15:20 +01:00
Gilles Dubuc 00d345f8b4 Rename Performance to PerformanceLogger
Change-Id: Iacfde35851cf8f617c4672d3ea466d4f0e2e448f
2014-11-21 11:07:40 +01:00
Gilles Dubuc ad5040a140 Add marker parameter to image requests coming from MediaViewer
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
2014-11-20 15:57:27 +01:00
Gergő Tisza c4c262bf44 Move logging-related code to its own directory
Also make sure class and file names have the same case.

Change-Id: I21042e40030051326f8c55fd62a86a54e9011a4a
2014-09-04 23:34:45 +00:00
Gergő Tisza fec24e02f7 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-05-01 21:09:28 +00:00
Gergő Tisza 59bd5e0032 Add tests for promise rejection error logging
Change-Id: I20d0803f211cbc4a7f00b58d015b565ca5c3b49b
Mingle:https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/268
2014-03-05 01:15:28 +00:00
jenkins-bot a5e566e5db Merge "Add rejection logging to providers" 2014-03-04 01:35:48 +00:00
Gergő Tisza ead038c34f Add rejection logging to providers
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
2014-03-03 21:35:01 +00:00
Gilles Dubuc 28cb881cfa Network performance measurement CORS improvements
- Fixes feature check for IE6 and older browsers without native XHR
- Skip crossOrigin attribute for IE11 because it prevents caching

Change-Id: I99d6a3c97edac1af12750d5978a84b6e6f631b14
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/232/
2014-03-03 17:17:07 +01:00
Gilles Dubuc 75dbc72e6c Better way to detect CORS support
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
2014-02-24 18:53:01 +00:00
Gilles Dubuc 28b8f5095e 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:
    8a8d74f01d.
    63021d0b0e.

Change-Id: I84ab2f3ac0a9706926adf7fe8726ecd9e9f843e0
Bug: 61542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-24 07:56:40 +00:00
Mark Holmquist 1733df8dc9 Grand Unified Documentation Patch Jr.
The GRUDP is dead, long live the GRUDPJ

Change-Id: I71a22c3aa42b2eb799ce8104159e8c7e56fe13ae
2014-02-21 00:55:43 +00:00
Gilles Dubuc 8a8d74f01d Avoid double requests when measuring performance of image load
Change-Id: Ib5ec4c3e4e4a410a6ee520b11bf025d7447cb542
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207
2014-02-18 16:45:03 -08:00
Gergő Tisza 7afbc5ce92 Use provider XHR information in performance metrics + several fixes
* 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
2014-02-19 00:38:27 +00:00
Gilles Dubuc 6e127b25e2 Preload prev/next images
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
2014-02-13 10:52:40 +01:00
Gergő Tisza 289ad22b19 Fix JSDuck
* update paths
* make generate script return failure state on failure
* fix some issues so that it does not actually fail

Change-Id: Idd42e0d8e333c461091079aa1150b1b435e6360c
2014-02-06 19:10:07 +00:00
Gergő Tisza 6068ffd58d Add provider to for actual image loading
Change-Id: I9ca9bce37c97648afa07db9f004138a791c74e65
Mingle: https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/123
2014-02-05 00:02:28 +00:00