Closed
Bug 296783
Opened 20 years ago
Closed 19 years ago
[adblocking] images not loading / missing content / distorted layout when "Block web advertising" enabled
Categories
(Camino Graveyard :: Page Layout, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jwise77, Assigned: sfraser_bugs)
References
()
Details
(Keywords: fixed1.8)
Attachments
(1 file)
|
8.41 KB,
text/plain
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050529 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050529 Camino/0.8+ In the GIF previews of these papers, the images do not appear in the left hand frame or the lower right frame. They appear in both Firefox and Safari. Maybe the image location is not being interpreted correctly? Reproducible: Always Steps to Reproduce: 1. Load the page and see for yourself 2. 3. Actual Results: No images Expected Results: Safari or Firefox
This WFM 20050604 using my own home-rolled userContent.css. However, I can reproduce Comment 0 using Camino's userContent.css installed when a user enables "Block web advertising" in the Web Features prefs (though I can't for the life of me figure out which rule is causing the problem). John, I assume you have that checked? If so, if you quit Camino and add the following line as the second line of the bottom section/list (the one that ends with display: inline !important } ) of your userContent.css file (located in username/Library/Application Support/Camino/chrome) img[src*="articles.adsabs.harvard.edu/"], then the images should reappear on your next visit to the site (you might have to empty cache and/or shift-reload the page). Alternatively, you can disable adblocking altogether and Camino will delete the userContent.css file. Please verify that you have adblocking enabled and that either adding the rule or turning off adblocking makes the images re-appear. On a bugzilla housekeeping note, I imagine this is the first of many bugs we're going to see about adblocking hiding some content that shouldn't be hidden. How should we handle and resolve them?
Summary: images not loading in this particular site (URL interpretation bug?) → [adblocking?] images not loading in this particular site (URL interpretation bug?)
Summary: [adblocking?] images not loading in this particular site (URL interpretation bug?) → [adblocking] images not loading in this particular site
Without adblocking or when I add the line, img[src*="articles.adsabs.harvard.edu/"], to my userContent.css, the images appear in the webpage now. To tell the truth, I wasn't aware of the addition of ad-blocking in Camino. I guess that new feature slipped by me since I already had it installed from Camino ExtraPrefs. I removed the ad-blocking rules from CEP and used Camino's rules. Both of them blocked the images in articles.adsabs.harvard.edu. While I was changing my userContent.css, I discovered which rule blocks the images in the mentioned URL. It's img[src*=".ad"] Wouldn't it be possible to have an icon appear where the pop-up blocker icon appears and ask the user if (s)he wants to whitelist this domain? I would imagine that would occur very frequently and become annoying. But on the other hand, users would have an easy way to whitelist content that is supposed to be displayed rather than editing userContent.css.
the standard ad-blocking rules plus my exception that's described in the comments
Disregard Comment 2. The images only appear when I turn off ad-blocking. The 20050529 build didn't contain an "inline ! important" section. Not knowing what I was doing, I changed "none" to "inline", and basically turned off ad-blocking. I've downloaded the 20050606 build, which has both "none ! important" and "inline ! important" sections. When I try to add img[src*="articles.adsabs.harvard.edu/"], the content still doesn't load. I'm attaching my userContent.css in case I did something stupid.
Well, part of the problem is that the images are also matching a:link[href*=".ad"] img, in your userContent.css file. When I comment out both that and the one identified in comment 2, the images display. I am still puzzled as to why the "override" rules (one for the img selector and one for the a:link... selector) aren't restoring the images, but I'm far from an expert in this CSS image blocking....
Mike, what do you want to do about this bug (and others like it that will pop up once people move to 0.9a/b/final and turn on ad blocking)?
Comment 7•19 years ago
|
||
how about we see how prevalent this is before we worry about it.
Comment 8•19 years ago
|
||
*** Bug 301951 has been marked as a duplicate of this bug. ***
Comment 9•19 years ago
|
||
The duplicate listed above is not a dupe since it did not use our adblocking file. However, I'm confirming this since it will / is / may become an issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** Bug 301951 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > The duplicate listed above is not a dupe since it did not use our adblocking file. Actually, that bug reproduces with Camino's stock userContent.css, too. > However, I'm confirming this since it will / is / may become an issue. This seems to be a big topic on the Camino list lately. I honestly don't know how to best address the problem...one size fits all doesn't with ad-blocking, but by and large I think the feature improves everyone's browsing experience. Samuel, can you see that something makes it into the release notes about the possible side-effects of the feature? Tweaking the summary to reflect what this bug is about more generally.
Summary: [adblocking] images not loading in this particular site → [adblocking] images not loading / missing content when "Block web advertising" enabled
*** Bug 302012 has been marked as a duplicate of this bug. ***
Summary: [adblocking] images not loading / missing content when "Block web advertising" enabled → [adblocking] images not loading / missing content / distorted layout when "Block web advertising" enabled
| Assignee | ||
Comment 13•19 years ago
|
||
I think the ad blocking is too generic. I don't think it should block anything based purely on dimensions. It should also not block stuff like tables or divs with specific sets of style rules. I think rules like iframe[src*="/ad/"], are also too broad. Currently, the ad blocking breaks the mozilla tinderbox 'L' links
Comment 14•19 years ago
|
||
(In reply to comment #9) > However, I'm confirming this since it will / is / may become an issue. I agree. I'd like to see an easy way to add a site to a whitelist. I'd also like a "reload page without ad-block" key combination/menu option. Perhaps when ad-blocking is off, this same option would reload the page WITH ad-blocking I'm a NASCAR fan - the http://fantasy.nascar.com page uses a single GIF to represent several buttons to get into their different games. Unfortunately the site's designer decided to call the GIF http://fantasy.nascar.com/images/ads/GamesAdvertisement.gif which of course gets blocked by the ad blocking and the links collapse and disappear. This is just one example. There are many others. I'd like to use the ad blocking but this is a real stumbling block (pun intended).
Comment 15•19 years ago
|
||
*** Bug 304517 has been marked as a duplicate of this bug. ***
*** Bug 304562 has been marked as a duplicate of this bug. ***
Comment 17•19 years ago
|
||
As the submitter of one of the later dupes (#304517) of this problem, I have read the comments to date, and also looked at userContent.css. My ignorant observation is that this looks like a classic programming dilemma of trying to anticipate all the possible forms of devilment a user could get themselves into. Maybe it's best to assume the user can deal with it. Specifically 1) document clearly that when ad blocking is on it might well explain why content they fully expect to see isn't there; 2) add an "ad blocking on" button down where the "pop-up blocked" button is, applicable to the current page only, and let the user decide to refresh with ad blocking off (of course, if the refresh just reloads what's in the cache....?); 3) let the user add (and delete) from the list. These ideas have been proposed previously. I add my vote. I think otherwise the blocking is going to cause a LOT of confusion and frustration and complaint once it becomes part of a "stable" version. I've already encountered it again. As a footnote, it might not hurt if this new button and the existing pop-up blocking button were to pulse a little, or do something down there to get the user to remember their existence and function. The current button is so small that if it does animate it would not be annoying, I have to think -- i.e. it would not merely replace one form of annoying screen noise with its own existence. The animation could also be offed as a Preference. All very easy for me to say.
*** Bug 304595 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 19•19 years ago
|
||
*** Bug 302547 has been marked as a duplicate of this bug. ***
Comment 20•19 years ago
|
||
Camino's adblocking now kills http://www.amtrak.com/ for me. All recent (0.9) previous versions of Camino did not. Mac OS 10.3.9, Camino nightly 2005082008 (0.9a2+).
(In reply to comment #20) > Camino's adblocking now kills http://www.amtrak.com/ for me. In what way? It appears to display identically for me with the pref on or off. 2005082004 (branch), 10.3.9--but amtrack is not in my regularly-visited list. Looks like you're using the trunk build. Simon, is this an interaction with bug 305026, which is on the trunk but not the branch?
| Assignee | ||
Comment 22•19 years ago
|
||
Depends on what userContent.css is left in the profile/chrome dir, i guess. We try to move it to one side, but if you run a combination of old/new biulds, the evil ad_blocking.css might get left there as userContent.css. I'm going to replace the evil ad_blocking.css with a less general one soon.
Assignee: pinkerton → sfraser_bugs
Comment 23•19 years ago
|
||
Amplification; clarification. My problem appeared to be some sort of cache-related issue. I'm not sure if it's Camino's fault, or if it's a system software issue. Camino version 20050819 (trunk) was blowing up with these sort of issues on a number of PhP sites. I deleted the nightly the way I'm supposed to, blowing away the cache file, Application Support folder, and program package. After emptying the trash, I installed Camino nightly 2005082008 (trunk) in the recommended manner. http://www.amtrak.com/ would load, but the various pull-down menus for train schedules would not display. So I posted my comment. This evening, after the Mac Camino was on had been put to sleep for some time, I fired up Camino again. This time the Amtrak site loaded fine, complete with the various pull-down menus. As I said, I'm not sure what's happening here, but wanted to give the development team some clarification/amplification of what was happening. Sorry for the spam. Thank you for your hard work on Camino -- it's been my primary browser for some time.
| Assignee | ||
Comment 24•19 years ago
|
||
*** Bug 305931 has been marked as a duplicate of this bug. ***
| Assignee | ||
Comment 25•19 years ago
|
||
I checked in new ad_blocking.css with more specific rules, on trunk and branch. Please file new bugs for any blocking failures, or sites that are broken because of this. Fixed on trunk and branch.
You need to log in
before you can comment on or make changes to this bug.
Description
•