Closed Bug 204290 Opened 22 years ago Closed 12 years ago

Patch: pref to prevent accidental following of links of blocked images

Categories

(Firefox :: Settings UI, enhancement)

x86
All
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: eric, Unassigned)

References

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030422 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030422 Mozilla Firebird/0.6 I have created a patch (that will be included) to ignore clicks on links for images which have been selected as "Block images from server". The feature can be enabled with: user_pref("imageblocker.disable_links", true); Reproducible: Always Steps to Reproduce:
This patch should ignore clicks to "blocked" images if the preference is set.
Attachment #122372 - Flags: review?(blaker)
I'm sort of curious as to what this is actually going to accomplish... if one has blocked images from a specific server then why would one then go and try to click on that image? And then of course, why bother making a patch to prevent something doing just that? Before we confirm this for review, I'd like to know the rationale behind this patch. I don't wish to discourage patch-making; I'm just curious as to the rationale.
OS: Linux → All
There have been others who may have described this better, but for me, when i am browsing in a multi-window setup, i will many times click on any blank spot on the page to get focus back for a window. cnn.com is the perfect example of this, where they have ads on the right hand side of the page, and when you disable the ad images, the right side of the page is white. so if i have another window in the foreground, and i click on the cnn window, the page automatically goes to the ad url that i didn't even know was there.
Thank you. So this is basically to create a pref to prevent the accidental following of links in blocked images if I understand it correctly. -->Changing summary Component --> Preferences Status -->Confirming as an enhancement request
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: General → Preferences
Ever confirmed: true
Summary: Patch: allow for "disabling" of links for blocked images → Patch: pref to prevent accidental following of links of blocked images
That is correct.
Severity: enhancement → normal
Component: Preferences → General
> That is correct. Eric, you just reversed David's changes while saying they're correct. Anyway, if I understand this correctly, you want a pref for this to be added to the Options window? If so, then I'm strongly against this bug. This would almost be a pref that wouldn't have a place in the Mozilla Preferences window, much less in the Mozilla Firebird Options window. Even if you don't want a pref to be added, I think this should not be changed anyway. I don't expect links to stop working because I don't want images to load. Recommend WONTFIX.
Excuse me, I didn't mean that there should be something in the GUI to enable/disable this option. Now as I re-read what he said, I see that is what he meant. I'm not sure what changes I reversed, but apologize if I was clumsy and reverted some changes in bugzilla. All I am proposing is a feature that can be enabled via prefs.js/user.js. I guess my point of making it an option that can be turned on an off is specifically because there will be some people (like you), who wouldn't expect that to happen, and others (like me, and some people who responded to my post in the firebird feature forum) who find the fact that it doesn't happen, annoying at times. Making it an option that defaults to being off makes it so that the default behaviour doesn't change, but if people decide they would like to not have links followed for images they've blocked, they can choose to do so.
Actually, I was going to leave it to the discretion of the devs, but personally I don't think it belongs in the Options dialog either and would only be accessible through about:config or user.js. About the only place I could see it going is in the images manager (when you click on Permissions) on a new tab in that manager. As for changes, this is an enhancement request, not a bug. There is nothing "buggy" about Firebird's behaviour with respect to this report. And the component is Preferences, not General (Preferences: "Bugs and feature requests for [Firebird] preferences. This includes the preferences manager as well as the preferences defaults"). Enhancement, by the way, does not mean "less important than trivial". Importance is measured by Priority, not Severity (and no Phx/FB bug I've ever seen has a Priority rating)
Severity: normal → enhancement
Component: General → Preferences
taking QA contact, sorry about the bugspam
QA Contact: asa → mconnor
Perhaps instead of blocking links from all blocked images, it would make more sense to frame the missing image (or perhaps shade it) to make it stand out (much like the Flash-click-to-download extension). I see the problem here as being not the fact that invisible images have active links, but more that there is no way of telling that such a link is present at all - I too have had the irritating problem of accidentally following a link I didn't know was there when shifting focus back to the browser.
*** Bug 226079 has been marked as a duplicate of this bug. ***
Sounds like the same problem.. only the patch does make firefox ignore the click.
Flags: blocking-aviary1.1?
This discussion can continue for a while longer ;-)
Flags: blocking-aviary1.1? → blocking-aviary1.1-
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change
QA Contact: mconnor → preferences
Assignee: bross2 → nobody
This behavior has annoyed me for quite awhile. I'd certainly like to see this included in a future FireFox release.
Attachment #122372 - Flags: review?(bugzilla)
Not going to add this functionality to Firefox.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: