Closed Bug 228471 Opened 21 years ago Closed 21 years ago

browser wastes time downloading blocked images

Categories

(Core :: Graphics: Image Blocking, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mozilla, Assigned: bugzilla)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 When images are blocked from specific sites, the browser still retrieves them even though it isn't going to display them. This is very noticeable over a modem connection. Reproducible: Always Steps to Reproduce: 1. Visit an ad laden page. 2. Block images from the ad servers. 3. Hit reload and watch the browser wait on the ad servers. Actual Results: A page that was already cached would not display for half a minute because the new banner ads had to be downloaded even though they were not to be displayed. Expected Results: The blocked servers should have been ignored and had no documents requested from them.
Check out AdBlock: http://adblock.mozdev.org/ This is likely a duplicate, but a few searches haven't turned up anything. Since many sites depend on ad views for revenue, this might be WONTFIX. A better solution that has a better chance of being accepted is for Mozilla Firebird to download blocked images LAST, so that the page displays quicker but still tells the website it's viewed the advertisement.
OS: Windows 2000 → All
Hardware: PC → All
Bug 94118 deals with the same issue and was resolved worksforme.
Thanks for the pointer to AdBlock. A couple points about your comment: The browser should put speed/efficiency concerns ahead of web site revenue issues. Also, requesting images for the purpose of billing advertisers for displaying the image when in fact the image is not going to be displayed sounds somewhat fraudulent.
Does this also happend with Mozilla Suite?
Bug 235150 has been just filled for Mozilla
*** Bug 235150 has been marked as a duplicate of this bug. ***
Confirming and switching to more specific Browser->Image Blocking component
Status: UNCONFIRMED → NEW
Component: General → Image Blocking
Ever confirmed: true
Product: Firefox → Browser
Version: unspecified → Trunk
Depends on: 191839
wfm. I blocked the image on top of this page (the link to mozilla.org), then started ethereal to capture the traffic, then pressed shift-reload, and observed no request for the image. only for the html file and the css file.
(In reply to comment #8) > wfm. I blocked the image on top of this page (the link to mozilla.org), then > started ethereal to capture the traffic, then pressed shift-reload, and observed > no request for the image. only for the html file and the css file. On the off chance that this was due to caching, I tried this test as well using Ethereal with a site I'd never visited before with this cache. I used IE6 to open http://starwars.com/, got the address of one of the images on the front page, confirmed it was from the domain starwars.com, copied the URL to Firefox and opened it. I then blocked the image, started Ethereal, and loaded <http://starwars.com/>. No requests were made for any images on the front page, which is crawling with virgin images to download. Therefore, it's not a possible cache issue, and this is (now, if not before) WFM as well. According to <http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#resolving>, if one more person finds this WFM, we can close this as WORKSFORME. Can anyone else confirm this? Reporter, do you still happen to see this behavior? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040318 Firefox/0.8.0+
Definitely WFM: Gecko/20040310 and Gecko/20031007 (other versions as well - I've tested this many times). The reason it didn't work here is probably that the page loads ads as IFRAMEs from the ad server, they cannot be blocked by the image blocker (though the images on it can). For IFRAME blocking you need AdBlock (it is using the same Content Policy API but is more flexible). Removing dependancy on bug 191839 (nonsense) and resolving this as WFM.
Status: NEW → RESOLVED
Closed: 21 years ago
No longer depends on: 191839
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.