From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.0rc1) Gecko/20020417 BuildID: 2002041711 Note: I am running the Linux build under FreeBSD 4.5-RELEASE Visiting this story: http://www.anchordesk.co.uk/anchordesk/commentary/columns/0,2415,7112100,00.html I noticed that I was seeing the ad in the middle of the page. I right-clicked to bring up the pop-up menu and noticed there was no "block images from this server" selection. I isolated the frame with the ad as being at this URL: http://ad.uk.doubleclick.net/adi/msgplus.zdnet.co.uk/anchordesk/westbrook;kw=;akw=;adid=;subse=;sect=anchordesk-westbrook;chan=anchordesk;sz=336x280;tile=1;ord=13422? Loading that frame by itself still exhibits the problem. Checking my block list I already have "ad.uk.doubleclick.net" listed as blocked. Reproducible: Always Steps to Reproduce: 1. Block images from ad.uk.doubleclick.net 2. Go to http://ad.uk.doubleclick.net/adi/msgplus.zdnet.co.uk/anchordesk/westbrook;kw=;akw=;adid=;subse=;sect=anchordesk-westbrook;chan=anchordesk;sz=336x280;tile=1;ord=13422? 3. See image. 4. Right click on image. Actual Results: "Block images from this server" did not appear in pop-up list, but image was still visible. Expected Results: Image should not have been visible.
It isn't an image - it's a flash animation.
Resolving as invalid. Note: There is RFE bug 70805 about blocking flash animations.
Got mail from reporter: "Not if you don't have the flash plugin installed. Looking at the source now (that you mentioned flash), it's doing an autodetection of Flash. Since I don't have the plugin it's presenting me with an image. That image shows even though I've blocked its server. Rick" -- Will try without flash - this may be a dup of bug 83047
Well the image when loading without flash installed is indeed a link. So that's why the context menu isn't showing. Why the image appears in the first place, when blocked, is the real issue here i guess. Reopen.
R.K.Aa, you said: "Well the image when loading without flash installed is indeed a link. So that's why the context menu isn't showing." I have narrowed this bug (situation) down to the use of the USEMAP attribute in the IMG tag. Is that what you meant? When the map does not cover the whole image, the image-related context items appear when I right click in the uncovered area, but not in the covered area (covered = "where the image map defines an area"). I think this is what you meant, but I didn't understand because when I hear "link," I think of an anchor tag. I guess we're on the same page here, but please confirm this is what you meant. I have found that just including the USEMAP attribute suppresses the appearance of the context menu items pertaining to images in general. But shouldn't the context menu items pertaining to an image appear regardless of whether the region of the image is "covered" by an image map? If there were just an IMG tag nested in an A tag, such as <a hRef="http://www.mozilla.org/"><img src="garbage.gif">, we would expect to be able to (and are able to) right click on the image and do image-type stuff with it. Why should this be any different (maybe there is a good reason, but I can't think of one). Maybe the real name of this bug/enhancement request should be the following: "USEMAP attribute in image tag suppresses image-related context menu items" That's my two cents. As for the "real question," why the image appears, I think that is a seperate bug. The original bug refers to the lack of "Block Images from This Server" context menu item, so I think that's what we should stick to here. The part of the summary saying "but shown images should already be blocked" was not related to the fact that the image context menu items don't appear for image-regions covered by an image map (and is maybe a seperate or related bug), because I don't have the images from that server blocked and I still experience this problem. I am using Win98, Build ID 2002042403 [phew]
So I guess what I mean is that this is exactly 83047 (plus a problem blocking images).... right? I thought I was so smart, too. ;)
I think I was hitting the B-rock when I tried to write this bug report (I thought it was one thing ["block images..." not appearing] and then realized there was an additional important detail [this image should already be blocked] that should be reported along with). If you'd like I can file a separate bug report for the "images not blocked from blocked server" part and we can mark the current bug as a dupe of bug #83047.
Rick, I think you have got the best solution. I am very much looking forward to fixes for related Bug 136091 and Bug 64068/Bug 133114. I think one problem is that people are not quite sure in what code the problem lives. In at least two other discussions on image blocking related bugs now, specifically whether problems live in image blocking and permissions or just in plain old imagelib (and no agreement seems to have been reached). I'll be there to confirm your new report, anyway (even if I can't actually mark it as confirmed). I wonder if the image were not a link (that is, the tag did not have USEMAP tag), and it was still remote, would Mozilla load the image anyway? I think I will check that. Would be interesting to know/narrow down before or after your report is filed.
In that last comment I meant that "In at least two other discussions on image blocking related bugs" I had read those accounts. I'm tired. Anyway. When I copied the source from your example URL and removed the part that makes it use the USEMAP attribute, the image was blocked correctly. So maybe the USEMAP attribute also makes image blocking in general work incorrectly (in other words, using USEMAP doesn't just suppress the image-related context menu items). Interesting.
So is this just added detail for the USEMAP blocking bug then?
It's hard to say which bug this is a dupe of, it turns out there are a few open bugs that are basically identical to this one (now that we've decided that it's all due to the usemap stuff). Bug 33853, Bug 83047 (as originally observed) are both likely candidates. It would be nice if someone else would clarify which is the right one. I have posted comments in both of those other bug discussions that refer to this bug so people will hopefully check out the discussion here. Either way, this bug definitely needs to be marked as a dupe (but its discussion is valuable).
Yep. This is the good old imagemap thing... :) *** This bug has been marked as a duplicate of 33583 ***