|Product:||WebKit||Reporter:||Thomas Fuchs <thomas>|
|Component:||Page Loading||Assignee:||Said Abou-Hallawa <sabouhallawa>|
|Severity:||Major||CC:||ap, beidson, bryan, chas.conway, dpaddock, graouts, ian, javan, jonlee, julio.viera, kyl3h0tchk1ss, lbzwischenbrugger, mrowe, paradox460, sabouhallawa, simon.fraser, tonikitoo, webkitbugzilla|
|OS:||OS X 10.4|
Description Thomas Fuchs 2006-01-18 15:12:26 PST
Comment 1 Thomas Fuchs 2006-01-18 15:13:26 PST
Comment 2 Mark Rowe (bdash) 2006-01-18 15:18:19 PST
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.
Comment 3 Chas Conway 2007-09-19 08:29:22 PDT
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. http://discord.itg.uiuc.edu/testing/MJPG_test.html 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.
Comment 4 Dave Hyatt 2007-09-19 13:31:46 PDT
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.)
Comment 5 Chas Conway 2007-09-19 13:42:00 PDT
(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?
Comment 6 Wichert Akkerman 2008-12-08 02:08:26 PST
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.
Comment 8 Bryan Field-Elliot 2009-04-17 12:53:51 PDT
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.
Comment 9 Kyle Hotchkiss 2010-01-28 12:23:34 PST
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.
Comment 10 Alexey Proskuryakov 2010-02-25 15:55:03 PST
*** Bug 35377 has been marked as a duplicate of this bug. ***
Comment 11 lbzwischenbrugger 2010-02-26 08:27:04 PST
Comment 12 lbzwischenbrugger 2010-03-09 03:22:36 PST
Here is a more komplex testcase: http://www.khtml.org/webkitbug/ 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.
Comment 13 paradox 2010-04-26 19:20:52 PDT
This script is probably the most common use of this technique http://www.appelsiini.net/projects/lazyload An example can be seen here: http://www.appelsiini.net/projects/lazyload/enabled.html
Comment 14 Alexey Proskuryakov 2011-08-26 15:42:33 PDT
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.
Comment 16 lbzwischenbrugger 2011-08-26 19:18:41 PDT
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: img.setAttribute("src",""); img.src=""; img.parentNode.innerHTML=""; img.parentNode.textContent=""; img.parentNode.removeChild(img); img.parentNode.replaceChild(img2); (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.
Comment 17 Brady Eidson 2018-06-05 12:24:50 PDT
Talking to a dev from BaseCamp right now at WWDC. "In other browsers, doing something to get an IMG created does not synchronously start a network load - That only happens after the runloop spins. WebKit synchronously starts the load, even JS immediately sets the src the null. This is super duper wasteful in our app (We clone dom trees, etc etc)"
Comment 18 Javan Makhmali 2018-06-06 08:01:32 PDT
Hello, another Basecamp developer here with more details. We use `MutationObserver` to detect when images are added to the DOM and swap their "src" attribute with a tiny placeholder image. Then we restore the original "src" as images are scrolled into the viewport. This technique is commonly referred to as “lazy loading” and is intended to avoid unnecessary network requests for images that may never be viewed. Due to this WebKit issue, our approach doesn’t work in Safari because the original image is always loaded. Additionally (this may be a separate issue), cloning <img> elements causes them to load *again* even if the cloned node is detached from the DOM. For example, running `document.body.cloneNode(true)` reloads all of its images. This affects our Turbolinks (https://github.com/turbolinks/turbolinks) library, which stores “snapshots” of pages by cloning them. I made a video to help illustrate the problem: https://www.youtube.com/watch?v=p6bkcjoyP1M In Safari (left), every image on the page is loaded initially, and then loaded again when scrolled into view. Cloning <body> loads all of its images once more. In Chrome (right), only the first image loads initially and the rest are canceled. Cloning <body> makes no additional network requests. My example application and its source code are available here: https://glitch.com/~jealous-moon Thanks for your time!