You need to
before you can comment on or make changes to this bug.
to an empty string or deleting the Image object) image loading continues in the background.
Created an attachment (id=5764) [details]
It seems logical to me that removing the image completely from the page by the three means shown
should cancel loading the image. Thanks for the great test case Thomas.
I was about to file a similar bug regarding identical behavior with MJPG streams. I am trying to switch an image's source between a static and motion jpeg file to save bandwidth when the video is not needed, but no matter what I do to it, short of reloading the page, it continues to load the MJPG data stream once it's been requested once.
This video stream may sometimes be black, but you will still see ~100KB/s in the activity monitor. This test case shows that the MJPG stream continues downloading after switching the src to a static image and even after deleting the image's DOM node.
This is actually by design. I can see how it would be bad if the resource is large though. (The idea is to go ahead and let the load complete so that the image gets into the cache to be resuable.)
(In reply to comment #4)
> This is actually by design. I can see how it would be bad if the resource is
> large though. (The idea is to go ahead and let the load complete so that the
> image gets into the cache to be resuable.)
That's good to know.
I don't know much about MJPG resources; can they be finite-length as well? In this case the MJPG stream is live and continues on forever negating any reason to try caching it. Is there a way to detect that the stream is not finite and cancel the behavior?
What was the design decision made here?
This issue breaks image lazy loading tricks, making pages with many images below the fold extremely expensive for people using webkit.
Can someone please advise what the status of this bug is? And what is the link in the previous comment for? ("<rdar://problem/6726455>"). Thank you.
http://www.appelsiini.net/projects/lazyload .. Why can't the model of this plugin just be applied, or maybe when it sees something like this used, it doesn't ignore it.
*** Bug 35377 has been marked as a duplicate of this bug. ***
Finish loading or not
a new Image will be loaded.
In some cases the previous loaded image is not fully loaded. It is a "nice
idea" to complete loading for caching reasons.
But there are some problems with that.
Loading continues also when an image Element is removed from
DOM tree or an Image object is deleted.
Dealing with partly loaded Images
I see 3 possibilities
A.) Continue loading even if the image is not requested anymore
WebKit Browsers continue loading. Firefox stops loading.
If the image is loaded to 99% it's cool to continue loading for cache.
If it's many times only 10% it makes the app slow.
B.) Stop loading, dump the partly loaded images
If the programmer needs to preload images he/she can do that with an Image Object.
It's also possible to create an Element with tagName "img" an, set the src Attribute and
C.) Stop loading, save the partly loaded images. If the image is requested again load the rest of the image.
That would be cool if it's really fast code.
I don't knoww if web servers loose speed with in aktive
"Content-Range" http header. This is als used for
large file downloads.
More details on this header:
There is no possibility for programmers to abort loading an image.
Webkit has a really fast image rendering and zoom engine.
For web applications (browser maps) that deal with lots of images
it's good to have excellent image rendering.
However, the user will not be really satisfied - because of this
image loading issue.
Here is a more komplex testcase:
It's webmap. if you zoom in/out very fast, firefox is fast loading the images.
Btw. if an images has in Etag but is in cache, the image could be displayed immediately. If the ETag has changed the picture on the page can be changed for the new one.
This script is probably the most common use of this technique
An example can be seen here:
It's my fault that this bug is about two separate issues now (removing an element or changing its src). Even though both are by design, these are not identical.
Perhaps bug 35377 should be un-duped.
I reopened bug 35377.
I reported bug 35377 and also made a comment here for the same bug.
For me it looks pretty much the same.
There are many methods to cancel image loading:
(maybe not complete)
btw. when I reported this bug I was in Cambodia and had a slow internet connection. Bandwidth was about 300 kBit shared for a guesthouse, the ping indicated that it was a satellite link.
Under this conditions webkit browsers are not the first choice mainly because of the bug I think.
Now I'm connected to the internet with a 10MBit line again and here I don't feel a bad impact of the bug. To find a good solution, the programmer maybe should simulate slow internet speed as you find in many parts of this world.
"netem" could do that for example.