Closed Bug 83047 Opened 24 years ago Closed 23 years ago

Block images from this server option does not appear when the image is a link

Categories

(Core :: Graphics: Image Blocking, defect)

Product:
Core
Component:
Graphics: Image Blocking
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.2alpha

People

(Reporter: aaargh, Assigned: morse)

Details

Block images from this server option does not appear when the image is a link, e.g. most banner ads. Build ID 2001052808
Over to blake since he's doing context menu cleanup and will likely fix this as he goes along.
Assignee: mpt → blakeross
Status: UNCONFIRMED → NEW
Component: User Interface Design → XP Apps: GUI Features
Ever confirmed: true
--> morse
Assignee: blakeross → morse
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
This may be off-topic for this bug, but a dialogue to put in sites-to-be-blocked manually in the preferences part would be good...
Too bad this one is targeted for so far off. The biggest reason by far to use image blocking, IMHO, is to avoid banner ads, which are usually links. This used to work in pre-0.9 releases, AFAIK. How does AOL feel about this feature <EG>?
Can you give a specific example in which this does not work.
As ovvldc said, it seems to not work on any site with a typical banner ad, for example. e.g. http://www.brunching.com/
If www.brunching.com is an example of this bug report, then I'd have to close it out as works-for-me. I definitely get the "block images from this server" entry in the context menu when I right-click on the banner ad from that site. Reporter, are there any other sites that demonstrate this problem, or is the problem no longer reproducible?
Sorry, I was way too terse in my last note. Sorry. www.brunching.com is an example of the bug for me because I have a line in my cookperm.txt file that looks like: flycast.com 1F i.e., block all images from this domain. Since the brunching.com banner is a flycast ad, the "block images" item on the context menu does not appear. However, the graphic DOES appear. Thus it is not clear if the bug is that linked images are (A) not successfully blocked or (B) the context menu "block images" item is incorrectly missing. The more I think about it, the more I think is is A, not B.
The description here sounds very clear to me: Block images from this server option does not appear It says that the option does not appear, not that the image is not blocked. If there is another problem whereby the option appears but the image is not blocked, then open a separate bug report -- don't morph this one.
I have the same problem, and i've reported it more clearly in #88286 as per morse's suggestion.
I just installed 0.9.2 yesterday and this bug seems fixed to me. I get the option at banner ads with a link in them and they block immediately on a reload. I am quite sure that it didn't work well in 0.9.1 and 0.9. It might have been that I don't visit sites with exotic banner ad providers. This would mean I had already blocked the servers and the images didn't get blocked as per #88286. However, I looked at my image permissions several times and I am very sure that at one point I got a banner from a site that wasn't listed but didn't show the option. Regardless, WORKSFORME now.
I never see the item "Block images from this server" in the context menu now a days, no matter whether the image is a link or not. Build ID: 2001 10 30 03 Preferences => P&S => Images => View Image Permissions displays an empty list. Have you guys given after for preassure from AOL ???
The same for me. The local menu option does not appear in Windows 2001102903 and Linux 2001102910 builds. The problem is much more serious now than when was originally reported. Increase severity because it makes the block image functionality pretty much useless.
Severity: normal → major
Keywords: mozilla1.0
OS: Linux → All
We've pretty much decided that Bug 140172 is a dupe of this bug, but I think that this bug is itself exactly a dupe of Bug 33583. Any opinions on that?
Um.. except this bug never mentions USEMAP....
Well, okay. It doesn't mention USEMAP, but keep in mind that Bug 140172 didn't mention USEMAP either until I mentioned it there. In fact, in that discussion R.K.Aa. noted that "Well the image ... is indeed a link. So that's why the context menu isn't showing." In other words, _exactly_ what is being discussed here. Bug 140172 had the incorrect summary that "block images from this server does not show on pop-up menu for this URL ...", and we figured out that the real problem was the same as Bug 33583, as you agreed. I had trouble understanding what people meant by "link" in that context, and in this one. In the other discussion it turned out to mean that the IMG tag used a USEMAP attribute to be covered by an AREA defined in a MAP. What does it mean here (if it means the same thing, then it is indeed a dupe of 33583 also)? Did people mean simploy an IMG tag nested in an A (anchor) tag? Either way, IMHO, I think it would be better to specify the actual element(s) meant by "link" (for example, an IMG tag nested in an A tag; or an IMG that has a USEMAP attribute). My problem in understanding what is meant is that there is no test case (for example, a small fragment of HTML that will allow someone to reproduce the bug). Maybe if the original reporter or someone who does understand what is meant by "link" can create such a test case, we can first figure out whether we are dealing with the same phenomenon as experienced elsewhere :)
Boris, may I have your attention on this (since you seem to know what's up here)? I now understand this bug, as clarified by the example URL http://www.brunching.com/ . It refers only to IMG tags nested in anchor (A) tags. So the summary should be changed, or at least understood to be inaccurate in its current form. I suggest the new summary: "Block images from this server option does not appear for an IMG tag between anchor (A) tags" As I said in my previous comment, I think the current summary is misleading and confusing because of the multiple meanings of the phrase "image that is a link" (which is why I took it to be the same as Bug 33583). Having said that, I think this bug should be resolved WFM. I do not observe this bug as described in my clarified summary at the site http://www.brunching.com/ anymore, or anywhere else, and I think it should be resolved WFM. If the problem people have is still that as described in Bug 88286 (See comments 7-11), then it can be discussed there. If someone can find this bug _exactly_ as I have clarified (perhaps as in Comment 12 & Comment 13, but that was last November), then they should report it now, or reopen it later, right? (I don't see it on Win98 Build 2002050408 or 20020429xx on Mandrake Linux 8.2) And lastly, we don't want to let this bug morph into 33583 if that is not what it is. Maybe Morse has more to say about this. Cheers
Update: the "block images from this server" context menu item doesnt appear when image is an imagemap. Please go to http://www.anekdot.ru and right-click on the top banner to see that.
P.S. Forgot to add: Win2000, buildID 2002052304
That's Bug 33583.
Dreadfully sorry for the spam, but I'm just trying to figure out: does anyone actually still see that the "Block Images from This Server" option does not appear for anything other than the useMap case covered in Bug 33583? I still maintain that this bug should be closed (because I see the "Block Images..." option for all <a><img></a> type links).
http://www.brunching.com/ WFM, build 2002061408/win98 I beleive this one is a dupe of Bug 33583, but the original reporter didn't investigate well enough to figure that out. Block Image works for me all the time, except for Imagemap case.
Component: XP Apps: GUI Features → Image Blocking
Marking WFM per comments from Shepperton and Wesha above. The only remaining problem is covered in bug 33583.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
vrfy
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.