140172 - block images from this server does not show on pop-up menu for this URL -- but shown images should already be blocked.

Status: VERIFIED DUPLICATE of bug 33583

(Core :: Graphics: Image Blocking, defect)

Description

[Rick Bradley]

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.

Comment 1

[R.K.Aa.]

It isn't an image - it's a flash animation.

Comment 2

[R.K.Aa.]

Resolving as invalid. Note: There is RFE bug 70805 about blocking flash animations.

Comment 3

[R.K.Aa.]

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

Comment 4

[Rick Bradley]

Could this be caused by Javascript generating the <img... code via
Document.write() ?

Comment 5

[R.K.Aa.]

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.

Comment 6

[R.K.Aa.]

changing component

Comment 7

[Dave]

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]

Comment 8

[Dave]

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.  ;)

Comment 9

[Rick Bradley]

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.

Comment 10

[Dave]

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.

Comment 11

[Dave]

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.

Comment 12

[Rick Bradley]

So is this just added detail for the USEMAP blocking bug then?

Comment 13

[Dave]

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).

Comment 14

[Boris Zbarsky [:bzbarsky]]

Yep.  This is the good old imagemap thing... :)

*** This bug has been marked as a duplicate of 33583 ***

Comment 15

[Paul Wyskoczka]

v