Bug 52581

Summary: preventDefault() in beforeload is not preventing image requests
Product: WebKit Reporter: Jeff <kunklejr>
Component: DOMAssignee: Nobody <webkit-unassigned>
Status: RESOLVED WONTFIX    
Severity: Normal CC: aestes, ap, aroben, darin, fam.lam, gavinp, jberlin, koivisto, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Mac (Intel)   
OS: OS X 10.6   
URL: http://www.nearinfinity.com/blogs/jeff_kunkle/lessons_learned_building_an_ht.html
Attachments:
Description Flags
Patch none

Description Jeff 2011-01-17 08:10:07 PST
Event handlers for Webkit's beforeload event can call preventDefault() to prevent a resource from being loaded into the DOM. However, it does not prevent the resource from being requested. 

For example, if I wanted to build a text-only version of my website, I could use the beforeload event to cancel loading of all image resources. Unfortunately, Webkit will make a network request for them anyway and just not place them in the DOM for display. This behavior defeats the usefulness of "preventing" the load since bandwidth will be used to download images that will never be shown.

Another example would be an ad blocker extension. While the extension could prevent ads from being displayed, it could not speed things up by preventing them from being requested over the network. In the same vein, while the user wouldn't see the ads, they would still be tracked by the ad service since the requests are made regardless of whether preventDefault() is called.

The beforeload event is great, but it would be even more valuable if calling preventDefault() on the beforeload event would cancel the request entirely.
Comment 1 Alexey Proskuryakov 2011-01-18 16:51:55 PST
This sounds like a good use case to me, but starting a network load only when there's a DOM element to dispatch the beforeload event on would make resource prefetching impossible.
Comment 2 Gavin Peters 2011-01-20 18:43:55 PST
Alexey, 

I'm confused: the problem Jeff's reporting is that preventDefault() in a captured beforeload doesn't work.  This means extensions like the Incognito extension don't actually work as advertised, since they share cookies with the remote site and make a request with a valid Referer.

Are you talking about bug 52577 instead?
Comment 3 Gavin Peters 2011-01-23 22:18:49 PST
Created attachment 79893 [details]
Patch
Comment 4 Gavin Peters 2011-01-23 22:21:56 PST
Comment on attachment 79893 [details]
Patch

I had some time on a flight today, and hammered out this test.  Unfortunately, it fails right now; as you can see if you run it, the request for the IMG is launched no matter what.

I poked at fixing it a bit, and there's something about how early the ImageLoader is consed up is our source of trouble: the capture isn't established the first time that ImageLoader::updateFromElement is called.
Comment 5 Andy Estes 2011-09-13 01:56:43 PDT
I noticed this when working on the patch for bug 45586. ImageLoader calls CachedResourceLoader::requestImage() before any beforeload work is performed. For the image case, beforeload only has the opportunity to stop a renderer from being attached to an image, not to stop the network request. This makes beforeload work differently for images than it does for other resources (e.g. beforeload can actually block the network request of an <object> or <embed>).
Comment 6 Darin Adler 2011-09-30 12:15:27 PDT
Retitled based on my understanding of what’s going on here.
Comment 7 Darin Adler 2011-09-30 12:16:33 PDT
But as Alexey pointed out, there’s a second issue because of preloading, so maybe my title change does not capture the entire issue here.
Comment 8 Andy Estes 2011-10-25 14:18:53 PDT
<rdar://problem/10343617>
Comment 9 Andy Estes 2011-10-25 14:23:51 PDT
Removing 'REGRESSION: ' from the title since I believe this bug has existed since beforeload was first implemented.
Comment 10 Andy Estes 2012-02-06 12:45:03 PST
Marking NTBF since this could only be resolved by disabling preload scanning for images.