I've used the following code in an embedded code field on Google Sites to display images on my website, it's all going well on my Windows, Linux and Android devices, but they don't show up on the iPhone (whether using Chrome or Safari)!
some context/constraints:
I'm pulling my images from my Google Drive. They are ~80kb JPEGs.
I'm using a HTML form as I have other elements (buttons, fields) which I've removed from the code extract below to focus on the issue. I need to keep this form.
Have you encountered this issue before?
<form name="submit-to-google-sheet">
<img id="img1" width=163 height=227>
</form>
<script>
const img1 = document.getElementById('img1');
img1.src = "https://docs.google.com/uc?export=view&id={imageGoogleDriveID}";
</script>
PS: I've explore the Base64 format which does allow to display the images on iOS-operated devices. It works if I just set the image source to a Base64 string. But I can't call a Base64 file from Drive as conveniently as a JPEG. I'm manipulating 250+ images so I can't either have the base64 strings in the middle of the code, it'd be too large to work with. I've tried to encode the images with base64_encode functions following this example but didn't manage to display anything. I've drilled so much that I'm actually wondering if it's the right way to go at all!
We just found the fix for iOS: when third-party cookies and cross-site tracking are blocked, the images don't load. The settings to toggle are explained here.
Base64 wasn't the solution, since the issue was coming from pulling images from my Google Drive, i.e. a different domain from my website.
I got an AJAX function that loads a png from a canvas graph element and does (per user choice) open the image in a new browser window or force a download.
While the first works without a problem, I got a problem with adding the file extension to the download. Currently I simply get none, using the following HttpHeaders: image/octet-stream, application/download(force-download, x-download)
Gladly some SO user put a JsFiddle together. 1)
Question: How could I go and append a file extension (.png/.jpeg) to the forced download as seen in the JsFiddle example?
1) Sry, but I don´t know the User name anymore.
Unfortunately, with data uris, it is not possible to supply filenames. You should probably look at the HTML5 BlobBuilder API - http://blogs.msdn.com/b/ie/archive/2012/01/27/creating-files-through-blobbuilder.aspx
Even with BlobBuilder, I've found that only Chrome acknowledges the filenames you supply, not Firefox.
i am developing a java web application which will be browsed using iPad safari through 3G\VPN connection, i have an IFRAME its SRC is a url to a servlet that sends a pdf file to the IFRAM
<iframe src="documentviewer?docid=#{viewIncomingBean.incoming.id}" width="610px" height="5000px"></iframe>
problems with IFRAM on iPad Safari are:
1 -after calculating the time taken on server side to flush the pdf file in the output stream to the client i found that the IFRAME takes a very long time to getting rendered and the pdf file loaded on client side (please have a look Using Iframes Sparingly).
2 - on iPad Safari the IFRAME can't be scrolled using regular one finger touch style, you must use two fingers to scroll the IFRAME up and down (please have a look ipad and iframe problem).
is there is any other better way to load the pdf file in a web page ????
I had to develop a pdf viewer for an ipad site we were working on. We could not make the scroll work with other thing but the two fingers.
What we did was to use http://mozilla.github.com/pdf.js
it is a javascript renderer for pdf documents. It works great ... of course, if you dont use IE.
another solution is to use the document reader of google ... https://docs.google.com/viewer
I've successfully integrated Flowplayer into my Drupal installation using the video and flowplayer. I upgraded flowplayer files to the latest release 3.2.7 and all works ok, but not on iPad - iPod Touch.
I loaded the js for the iPad plugin in the Flowplayer module like this:
drupal_add_js(drupal_get_path('module', 'flowplayer') . '/flowplayer/example/flowplayer.ipad-3.2.2.js');
and I see that it is loaded fine.
then in Flowplayer js I had this line
$(selector + ':not(.flowplayer-processed)').addClass('flowplayer-processed').flowplayer(settings.basePath + settings.flowplayerSwf, config);
I changed this in this way:
//I added the first line because in the example it worked that way
$(selector + ':not(.flowplayer-processed)').attr('url', config.clip.url);
$(selector + ':not(.flowplayer-processed)').addClass('flowplayer-processed').flowplayer(settings.basePath + settings.flowplayerSwf, config);
//then i add ipad support (the selctor is hardcoded to maike things work)
$f('flowplayer-video').ipad();
In this way, on my iPod touch (I think it's the same on iPad) I see the player but the video doesn't start (there is some kind of blocked overlay).
You can look at the site here
EDIT - now i got it working thanks to teddy suggestion. now i'll try to find out how to setup my script so that it returns byte-range headers.
If anyone knows how to do this, please post here.
The server that serves the actual MP4 video to the iPad must support the HTTP header called byte-range.
I would try using an alternate video source from another server, as a proof-of-concept to see if this is the cause of the problem.
Here is an MP4 video served with the byte-range header: http://mediaelementjs.com/media/echo-hereweare.mp4
Suppose in Javascript that you assign the SRC to an IMG tag. It is a large SRC and you want to cancel it before it has finished loading. Assigning the SRC to another image will not stop the data from loading.
That is, in the middle of the load you can assign the SRC to another smaller image and the smaller image will be loaded and appear in your browser. However, the original SRC still continues downloading.
Similarly, deleting the IMG node will not prevent the SRC from continuing to download. No guesses please, look at the repro steps.
REPRO
Load this URL in Chrome in Windows: http://68.178.240.17/imgLoadTest/imgLoadTest.htm
Open up the developer panel by pressing CTRL-SHIFT-J
On the top row of icons in the Chrome developer panel click the Network icon to watch network activity.
On the web page loaded in Step 1 click the Load Image button and watch the developer panel as a large (32meg) image starts loading.
On the web page click the Try To Cancel button to load a different image.
A small image loads, but watch the network in the developer panel and notice that the large image continues to download.
Quick answer
Setting the src attribute of the img tag to the empty string will interrupt the current download, even on Chrome.
Details
Nowadays most of browsers implemented that out-of-standard mechanism thought in the old answer to programmatically abort the connection. This is not achieved through a protocol request, but with a client-side in-memory operation. Keep in mind that is not a standard behaviour, but most of vendors courtesy. That is, it could not work on every browser.
I've prepared a jsfiddle showing this mechanism in action (keep an eye at the network panel of the inspector).
Old answer (2011)
Your browser asks for that image with a specific HTTP GET request, as specified in HTTP protocol. Once it asks for it, the http server starts the transfer.
So, it is between the browser (as http client) and the http server.
Since http protocol does not takes into account the option to abort a transfer, the browser should implement a out-of-standard mechanism to programmatically abort the connection. But since this is not specified in any standard, i think you won't find any way to do that with javascript or any client side code.
Cancel with transparent base64 encoded GIF to avoid additional requests and double page load on android:
var img = new Image();
img.src = 'http://google.com/favicon.ico';
img.src = 'data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEAAAAALAAAAAABAAEAAAI=;'
Although I can't find the bug report now, I believe this is a long-standing logged WebKit bug. Firefox (and IE I think) have more sane behavior. I'm going back a bit in my brain, but if I recall on those browsers, resetting the img.src will in fact cancel outstanding downloads. I am positive that Firefox does this when a download is "waiting in line" for a chance at an open HTTP connection, and I seem to recall that it will actually force close connections sometimes.
I've never found a way to coax WebKit based browsers into cancelling an img download in progress, whether it is just queued or already actively downloading.
This really sucks if you're making something like a mapping client and need more fine grained control over images.
Setting the .src property to an empty string should cancel the load:
//load image from url
var img = new Image();
img.src = 'http://somedomain.com/image.jpg';
......
//cancel load
img.src = '';
Yes, page is downloaded twice on Android when an img tag has an src="" attribute.
This still occurs on recent Android versions.
I have not found any other browser that does that.
But I found a solution: use an img tag without src attribute.
The ultimative answer is web workers.
Load the image inside an webworker and stopping the web worker will stop the image loading.
You can get the idea from this code:
https://github.com/NathanWalker/ng2-image-lazy-load
this work for me:
imageVarName.src = '';
imageVarName.onload = null;
imageVarName.onerror = null;
the src property must be a valid non-empty URL
So null or empty string are not legal (even though they sometimes work).
Use:
img.src='http://xxxx';
img.onerror=null;
(see here)
Sadly, setting src to an empty string does not work in WebKit-based browsers like Safari. Here is the link to the bug report which Stella mentioned.
https://bugs.webkit.org/show_bug.cgi?id=6656