Bug 52581 – preventDefault() in beforeload is not preventing image requests

• Status: RESOLVED
• Resolution: WONTFIX
• Component: DOM

[Jeff]

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.

[Alexey Proskuryakov]

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.

[Gavin Peters]

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?

[Gavin Peters]

Created attachment 79893 [details]
Patch

[Gavin Peters]

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.

[Andy Estes]

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>).

[Darin Adler]

Retitled based on my understanding of what’s going on here.

[Darin Adler]

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.

[Andy Estes]

<rdar://problem/10343617>

[Andy Estes]

Removing 'REGRESSION: ' from the title since I believe this bug has existed since beforeload was first implemented.

[Andy Estes]

Marking NTBF since this could only be resolved by disabling preload scanning for images.