Closed Bug 98554 Opened 23 years ago Closed 2 years ago

accidentally clicking anchors of blocked images

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: chris+bugzilla, Unassigned)

References

Details

(Keywords: helpwanted)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.3+) Gecko/20010904
BuildID:    20010904

I'm a heavy user of Mozilla's "block images" feature.  I love it, but there's a
problem: I keep clicking through the link associated with the images by mistake.
 The reason I do this is that focus is occasionally in the different part of the
browser front end (e.g. the location bar) so I click a blank part of the page to
get focus in the browser pane (so I can use arrows to scroll, etc).  Often,
however, those "blank" parts of the page are where the image would have been if
not blocked.  The "border=0" attribute is often set in the img tag, so there is
no indication (other than the cursor change, which I don't always notice) that
the region is active.

I'm not sure what would make a good solution.  Some obvious candidates:
1) deactivate anchors around blocked images
   -- bad because it removes nav functionality
2) use an alternate icon for blocked images
   -- unattractive
3) turn the border on so you see an empty anchor rectangle instead of the image  
   -- unattractive, may disrupt layout appearance

Since I can't think up a good solution myself, I'd be interested in hearing
suggestions from others.  I like the way pages look with blocked images (lots of
blank space) but my accidental click-throughs are annoying me.
This is related to bug 62046.

Also, see bug 11011 -- that would allow styling of the blocked images...
Yes, it seems that showing the alt tag (if any) would be the correct solution. 
This bug should depend on bug 62046, with the understanding that blocked images
should fall under the category of "don't show" images for layout.
Depends on: 62046
Confirming issue.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
*** Bug 108881 has been marked as a duplicate of this bug. ***
I think that blocked images should be displayed in a manner similar to the way
that broken images are now displayed by default. An etched frame should be
visible that occupies the area that the blocked image whould have taken up.

However, I think there should be a different icon indicating that the image has
been blocked. Also, unlike broken images, I think the alt text should not be
displayed. The whole point of this image blocking is to block unwanted content
such as ads. Displaying the alt text would be at odds with this purpose.

This solution will not disrupt the layout because, the way etched frames for
blocked images are currently implemented, images or colors behind the frame show
through. On the other hand, collapsing the space occupied by blocked images
could very well disrupt a page's layout.
I think the block image should show a frame, but the hyperlink/click action
should just be removed.

By seeing a frame present, I can determine myself that there may be an image to
unblock, but it is actually very useful to have blank space on which to click
(and so grab focus).  When I have a blocked image, I can't image EVER wanting to
be able to click on it and go to the target.

So I would remove the hyperlink/click action unless the user modifies the click
with a SHIFT, or CTRL, ALT, or double bucky.
*** Bug 124793 has been marked as a duplicate of this bug. ***
*** Bug 125549 has been marked as a duplicate of this bug. ***
What about just disabling the anchor when on a blocked image.. (At least as an
option). The images that I block are banners ads, and I am pretty sure that I
dont want to click on them.
Responding to #9:
Absolutely not.  If you disable anchors, you are messing with the page author's
intentions.  That's no better than MS trying to add anchors to their keywords in
IE6.  I actually use the anchors under blocked images sometimes (e.g. I block
all slashdot images, but I know where the link to their home page is and I use it).

Note: I am the reporter of this "bug" and have long since decided that there is
no easy solution.  I advocate either printing the alt tag on blocked images, or
closing this bug and leaving the functionality as-is.

Probably a bad idea, but a solution would be to let this be a user pref on the
privacy->images page.  Some thing like the following checkboxes:
  o Show icon for blocked images
  o Show alt text for blocked images
  o Draw border marking blocked images
(the last would be troublesome on 1x1 images)

One more note: I disagree with comment #5 that blocking images is just for ad
blocking and that displaying the alt text is therefore a mistake.  I use image
blocking primarily as a bandwidth enhancer.  As it happens, that means that most
of the sites I block are ad sites.  But that doesn't mean I'm anti-ad.  I would
prefer to see the alt-text of blocked images to see what I'm missing.
Reponse to comment #10... I'm the user, and I think that I have every right to
ignore the author intention, the same way that I already do when I block pop-ups
and pop-unders, etc.. I'm not at all asking that killing as the anchor be the
default behavior, but to be just an option, even an option that's not accessible
from the ui.
Ok, sorry.  I thought you meant as the default behavior.  As a pref, that would
be fine with me.
Is this bug still alive? Anyone working on it?
If someone were, it would be assigned to that someone, marked "ASSIGNED", and a
target milestone would be set.  Not to mention that the someone would generally
have commented saying that he or she is working on it.
I'm the reporter of this bug, and I've trained myself to not click where there
might be an undisplayed image.  I'm stopped caring about this bug, so I'm
willing to mark it WONTFIX.  What do the four voters say?  Keep the bug open or
drop it?
Err.. I have also somewhat trained myself too, but if I get some free time, I'll
try to fix this bug..  But I dont have much of right now..
I vote it stays open, but I'm not expecting it to get fixed any time soon, which
is fine with me. The only time it really bugs me is if there's multiple frames
on the page and I have to click inside one frame so I can scroll. Sometimes I
end up hitting an undisplayed image. So no, I haven't trained myself entirely,
but like I said, it's not killing me either.
Sorry, didn't mean to sound rude with comment #13, but I got the conversation
going again, didn't I?  :)

I haven't trained myself to avoid doing this. I find it usually hits me when
Mozilla is below another window and I click it to raise it to the top. If I can
only see a small corner of the Mozilla window it's hard to tell whether it's
safe to click there. When the mozilla window has several tabs open it's even
harder to remember whether a particular bit of the window is a link or not if
all you can see is a plain white area. This regularly happens on
http://www.theregister.co.uk/ where I've blocked the doubleclick.net images. I
often find myself clicking the right edge of the window to raise it, because it
looks like a blank white space.

Although I vote for keeping it open, this isn't a terribly big deal for me
either. At the worst I have to hit escape or back to stop the doubleclick page
from loading, but one of the fixes proposed here would be better than WONTFIX
and would IMHO make the image blocking even better than it is. If I had the time
and the disk space to start hacking on Mozilla I'd try to change this myself,
but until I do, feel free to ignore my whinging!
*** Bug 187098 has been marked as a duplicate of this bug. ***
So... Is this still a problem?  The image loading changes changed this behavior
somewhat....  It should no longer be an issue when image loading is turned off
entirely, though the "load images from originating server only" case is still
broken.
I would say it's still an issue. Most annoyingly, the "block images from this
server" feature still has this problem (as of 2003041009 anyway). Since the only
purpose of this feature is to block ads (more or less :-), that means that
accidental clicks on the invisible anchor are the most likely variety to
generate popups, and other obnoxious stuff you don't want to look at.

Also, people turning off images entirely has got to be considered a *very*
minority position.
> (as of 2003041009 anyway)

Not useful.  I checked in patches on later than that that should have fixed that
problem, which is why I asked whether it was still an issue right after I
checked them in....
Still happens on 2003042804 on cnn.com (ad link is:
http://ar.atwola.com/link/93103349/html?badsc=B0KI4sIU7dtHAQElYXWFiiH3dLuYhRIMeexHnJBcISMfN-OSg0mZJ6dln_ia0eHm1dEnUGux3SDkoxCQvuSbuP94W8P5fHzY-fLzr6NMtTu9mFKl6BwlVJLWgLok7NCoDd2bvmsUVLSuYOU7jhyzsFvA$$,
and that server has images blocked). Mousing over the location where the ad
would normally be gives a "follow link" cursor, and clicking follows the link. 

OK.  So you're allowing images in general but blocking images from that one
site?  And you are getting neither alt text nor broken image icon.  Right?
Re: comment 24, yes that's correct. My experience (and feelings) are the same as
comment 18.
I plan to work on this area of code sometime in the 1.5 or 1.6 milestone, so
please do keep this open.  ;)
For the images mentioned in comment 23, does the image have a background style
associated with it?  (check in DOM inspector?)
Re: comment 27, the easiest way to tell this would probably be to go to cnn.com
yourself. Every article has either an image or flash ad on it (randomly
generated). Pick some article and reload it until you get an image ad.

I did this, and there doesn't seem to be a background attribute on the image,
but I'm no expert with the DOM inspector. 

One slightly odd characteristic of this image is that it's inside an IFRAME
inside a DIV inside a TD... No idea if this is a clue or useless data. 

Here's the HTML in the IFRAME for my test example:

<a
href="http://ar.atwola.com/link/93103266/html?badsc=B0BelzdA-abceK5oAbpob3aQsmLaUxorjj1H0h8HPCSssiy1XbHCA4f-36wt3h1yCZqhfIGkcvtWKuEHCpGoPMxNVOOGh8EBBGQ4B1L5bKfhRsy_LujgvKJ8FlGal5v0brAgsBaV3WBsZeNOlDwIkvOs3E28MFkKK9L3Unn-TjJHM$"
target=_top><img
src="http://view.atdmt.com/COL/view/mrcnachm00500882col/direct/01/?Any&time=2003.05.03.22.08.50"
border=0 height=600 width=160 alt="Advertisement"></a>
Ah, ok.  I see the problem now...

So the deal is that HandleLoadError() bails out of creating the replaced alt
text, but this, of course, leaves the image frame in place.  It doesn't show the
alt text, but it's still sized to the size that's set in the <img>'s attributes.

So what we should do is to make sure we blow away the frame, and fix
CantRenderReplacedElement to handle this correctly.
Depends on: alttext
->bz, since attinasi's gone and you know what to do
Assignee: attinasi → bz-bugspam
Er... how did I end up with this bug?

Fixing this requires fixing the general brokenness that is
CantRenderReplacedElement.... not something I plan on doing anytime soon.
Assignee: bzbarsky → jdunn
Component: Layout → Layout: Images
Keywords: helpwanted
QA Contact: chrispetersen → core.layout.images
Target Milestone: Future → ---
*** Bug 245065 has been marked as a duplicate of this bug. ***
*** Bug 246832 has been marked as a duplicate of this bug. ***
(In reply to comment #31)
> Er... how did I end up with this bug?
> 
> Fixing this requires fixing the general brokenness that is
> CantRenderReplacedElement.... not something I plan on doing anytime soon.

I want to block images but I want to see the surrounding anchor and the ALT
attribute. I would like to have a Mozilla-is-Lynx browsing mode.

Just my vote.
(In reply to comment #34)
> I want to block images but I want to see the surrounding anchor and the ALT
> attribute. I would like to have a Mozilla-is-Lynx browsing mode.

then disable images in preferences/privacy&security/images, and restart the browser.
*** Bug 288494 has been marked as a duplicate of this bug. ***
Bug 204290 has a patch, i suggest this bug be duped.
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Severity: minor → S4

The severity field for this bug is relatively low, S4. However, the bug has 7 duplicates and 11 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(emilio)
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(emilio)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.