Closed
Bug 228471
Opened 21 years ago
Closed 21 years ago
browser wastes time downloading blocked images
Categories
(Core :: Graphics: Image Blocking, defect)
Core
Graphics: Image Blocking
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.
Comment 1•21 years ago
|
||
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
Reporter | ||
Comment 3•21 years ago
|
||
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.
Comment 4•21 years ago
|
||
Does this also happend with Mozilla Suite?
Comment 5•21 years ago
|
||
Bug 235150 has been just filled for Mozilla
Comment 6•21 years ago
|
||
*** Bug 235150 has been marked as a duplicate of this bug. ***
Comment 7•21 years ago
|
||
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
Comment 8•21 years ago
|
||
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.
Comment 9•21 years ago
|
||
(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+
Comment 10•21 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•