Last modified: 2014-02-24 09:59:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T63542, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 61542 - src attribute of image in MMV view is not related to src of image in page
src attribute of image in MMV view is not related to src of image in page
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
MultimediaViewer (Other open bugs)
unspecified
All All
: Unprioritized minor (vote)
: ---
Assigned To: Nobody - You can work on this!
: browser-test-bug
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-02-19 16:30 UTC by Chris McMahon
Modified: 2014-02-24 09:59 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
long src for image in MMV (541.03 KB, image/png)
2014-02-19 16:30 UTC, Chris McMahon
Details

Description Chris McMahon 2014-02-19 16:30:15 UTC
Created attachment 14628 [details]
long src for image in MMV

Seen as of Feb 19 in http://en.wikipedia.beta.wmflabs.org/wiki/Lightbox_demo

This may be expected behavior and a WONTFIX... 

Images in the MMV page seem to have acquired a src attribute that is very long, and that is unrelated to any aspect of the original image in the page.  The behavior of MMV seems OK, but this causes the current MMV browser test to fail, see screen shot.  

(I would like to re-work this test a bit in the near future, also)
Comment 1 Brion Vibber 2014-02-19 18:00:21 UTC
There are a couple of distinct issues here:

1) the src isn't just the http(s) src as expected, and

2) the src is a data: URI, which is horribly inefficient

One could fix 2) by loading a blob instead of an ArrayBuffer and using createObjectURI()... but it would still be a URL that can't be copy-pasted usefully.


However I would probably recommend simply loading the image an an invisible <img> rather than an XHR; you won't get a chance at a full progress bar (just a delay then 'onload' or 'onerror') but the image will interact with things more or less as expected.
Comment 2 Tisza Gergő 2014-02-19 19:16:06 UTC
The reason for using XHR is that we want to access the headers so that we know whether the image was a cache hit on varnish, and if not, how is loading time split between thumbnail generation and real loading. (Anecdotally, slow rendering seems to be a big issue, with multiple-second image loading times, but we don't now how prevalent the problem is.) On production, this would only happen in an 1/1000 sample, not every request.

The original plan was to preload images via XHR, then set the src to the same URL as in the XHR request, but at least in current Chrome, that causes the image to be re-requested.
Comment 3 Gerrit Notification Bot 2014-02-20 03:24:20 UTC
Change 114403 had a related patch set uploaded by Gergő Tisza:
Use cross-origin img attribute instead of data URI

https://gerrit.wikimedia.org/r/114403
Comment 4 Tisza Gergő 2014-02-20 03:38:45 UTC
We are abandoning data URIs, see commit message and https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207 for details.
Comment 5 Gerrit Notification Bot 2014-02-24 09:47:01 UTC
Change 114403 merged by jenkins-bot:
Use cross-origin img attribute instead of data URI

https://gerrit.wikimedia.org/r/114403

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links