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)
Core
Layout: Images, Video, and HTML Frames
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.
Comment 1•23 years ago
|
||
This is related to bug 62046. Also, see bug 11011 -- that would allow styling of the blocked images...
Reporter | ||
Comment 2•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: --- → Future
Comment 4•23 years ago
|
||
*** 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.
Comment 6•22 years ago
|
||
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.
Comment 7•22 years ago
|
||
*** Bug 124793 has been marked as a duplicate of this bug. ***
Comment 8•22 years ago
|
||
*** Bug 125549 has been marked as a duplicate of this bug. ***
Comment 9•22 years ago
|
||
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.
Reporter | ||
Comment 10•22 years ago
|
||
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.
Comment 11•22 years ago
|
||
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.
Reporter | ||
Comment 12•22 years ago
|
||
Ok, sorry. I thought you meant as the default behavior. As a pref, that would be fine with me.
Comment 13•22 years ago
|
||
Is this bug still alive? Anyone working on it?
Comment 14•22 years ago
|
||
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.
Reporter | ||
Comment 15•22 years ago
|
||
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?
Comment 16•22 years ago
|
||
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..
Comment 17•22 years ago
|
||
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.
Comment 18•22 years ago
|
||
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!
Comment 19•22 years ago
|
||
*** Bug 187098 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
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.
Comment 21•21 years ago
|
||
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.
Comment 22•21 years ago
|
||
> (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....
Comment 23•21 years ago
|
||
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.
Comment 24•21 years ago
|
||
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?
Comment 25•21 years ago
|
||
Re: comment 24, yes that's correct. My experience (and feelings) are the same as comment 18.
Comment 26•21 years ago
|
||
I plan to work on this area of code sometime in the 1.5 or 1.6 milestone, so please do keep this open. ;)
Comment 27•21 years ago
|
||
For the images mentioned in comment 23, does the image have a background style associated with it? (check in DOM inspector?)
Comment 28•21 years ago
|
||
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>
Comment 29•21 years ago
|
||
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
Comment 30•21 years ago
|
||
->bz, since attinasi's gone and you know what to do
Assignee: attinasi → bz-bugspam
Comment 31•20 years ago
|
||
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 → ---
Comment 32•20 years ago
|
||
*** Bug 245065 has been marked as a duplicate of this bug. ***
Comment 33•20 years ago
|
||
*** Bug 246832 has been marked as a duplicate of this bug. ***
Comment 34•20 years ago
|
||
(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.
Comment 35•20 years ago
|
||
(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.
Comment 36•19 years ago
|
||
*** Bug 288494 has been marked as a duplicate of this bug. ***
Comment 37•18 years ago
|
||
Bug 204290 has a patch, i suggest this bug be duped.
Assignee: jdunn → nobody
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
Updated•2 years ago
|
Severity: minor → S4
Comment 38•2 years ago
|
||
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)
Comment 39•2 years ago
|
||
See bug 204290.
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.
Description
•