Closed Bug 533247 Opened 15 years ago Closed 15 years ago

Speculative load might result in loading too much


(Core :: DOM: HTML Parser, defect)

Not set





(Reporter: jwkbugzilla, Unassigned)



Users reported that images blocked by Adblock Plus are still being downloaded in Firefox 3.6. My investigation shows to bug 457809/bug 457810 as the cause of this issue. The content policy implementation in Adblock Plus tells the browser to block the load but at this point the image has been loaded speculatively already. From what I can tell, there is no content policy check when loading stylesheets speculatively either. The loaded image/stylesheet is discarded by the browser of course but this wastes bandwidth. I can imagine this being particularly a problem in Fennec.
Flags: blocking1.9.2?
Dão, I don't think this is blocking. We are talking about a significant performance improvement here, it is beneficial for most users. There is an undesirable side-effect but from what I can tell there isn't an easy solution that could be implemented before Firefox 3.6 release. This bug is basically there to ask whether there is a viable solution at all or whether we have to live with it. It's not like all ads will be downloaded in Firefox 3.6, only things that are linked to in the HTML source of the page are loaded speculatively - so not something that is inserted dynamically by scripts. And even blocked images that the page includes directly aren't loaded every time.
Flags: blocking1.9.2?
We could call the content policy for speculative loads as well, just with less context information. I think that would be the right thing to do.
Yes, the script loader does that already so it would be consistent. However, for scripts null is being passed as context parameter (bug 464754) - this is not enough information for Adblock Plus to work on. Usually, Gecko send the document node as context meaning "no idea which node triggered that request" - Adblock Plus can deal with that (other than mistaking image loads for background images which is minor). Don't know about other content policies, I think most of them don't consider the context.
Actually, nsWebBrowserContentPolicy considers the context. And this bug also implies that users who disabled images in the browser will still end up loading images occasionally even though these images aren't displayed (verified on the Firefox start page).
We fixed script preload calls, though. Right? There isn't any reason we can't pass the document for preloaded images and stylesheets.
Blake, I wasn't sure any more so I checked. Yes, the first content policy call for scripts has the document node as context and Adblock Plus is able to block it, no download started. So doing the same for images and stylesheets should fix the issue.
Let's request blocking1.9.2 again - looks like this is relatively easy to fix after all. And given that this issue affects browser's built-in functions as well (unchecking "Load images automatically" doesn't save bandwidth as it should) this should be worth the attention.
Flags: blocking1.9.2?
Not blocking, but if you write up a patch I think we'd take it. If nothing else we'd take it for a dot release.
Flags: blocking1.9.2? → blocking1.9.2-
Apparently, bug 540642 fixed this for images on trunk. And it seems that stylesheets didn't even have this problem, CSSLoaderImpl always calls content policies. Can somebody with the right permissions check whether bug 540642 will land on 1.9.2 branch? If so, please dupe this bug against it.
Looks like that's the plan
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.