Closed
Bug 287571
Opened 19 years ago
Closed 19 years ago
Remove UI for 'Load Images for the originating web site only' pref
Categories
(Firefox :: Settings UI, defect)
Tracking
()
RESOLVED
FIXED
Firefox 2 beta1
People
(Reporter: ali, Assigned: Gavin)
References
Details
(Keywords: fixed1.8.1)
Attachments
(3 files)
4.97 KB,
patch
|
mconnor
:
review+
|
Details | Diff | Splinter Review |
2.74 KB,
patch
|
mconnor
:
review-
|
Details | Diff | Splinter Review |
5.02 KB,
patch
|
mconnor
:
approval-branch-1.8.1+
|
Details | Diff | Splinter Review |
We should remove UI for the 'Load Images for the originating web site only' pref. This pref is easily misunderstood by the majority of the web browsing population, and we get questions like: "Why aren't images on Yahoo! loading?" I don't most expect users to know that Y! is serving images off yimg.com and therefore so-and-so pref is causing images not to load. We need to get rid of the UI for the pref so that people can't enable something that has non-obvious implications. The issue of contention is how do we migrate users who already have the preference set who upgrade to 1.1?
Comment 1•19 years ago
|
||
Just turn off the pref for 1.1 users and revert them to Load Images From All and add a Release Note about this. Even more confusing for the users who accidentally turned this on would be that there's no GUI to fix it once they've upgraded.
Comment 2•19 years ago
|
||
I seen several bug reports about images not showing up due to this pref. Some of them have asked why you cant see a placeholder for the blocked images on the page. I agree that this is a confusing pref that should be hidden.
Comment 3•19 years ago
|
||
I was mulling over filing the same bug. I examined alexa's top ten english site's front pages. http://www.alexa.com/site/ds/top_500 yahoo - no images at all msn - lost an ad or two google - no differece passport - missing some graphics ebay - realy broken, no images, layout affected microsoft - lost an ad or two amazon - no differece aol - ad will not load - main content on page fastclick - no differece google.co.uk - no differece
Comment 4•19 years ago
|
||
(In reply to comment #3) > amazon - no differece amazon.com - no difference. European Amazons load images from images-eu.amazon.com (see another twenty or so bugs).
Comment 5•19 years ago
|
||
Well lets see if we can get this on the radar before the 1.1 branch.
Flags: blocking-aviary1.1?
Comment 6•19 years ago
|
||
I think you should leave the option there but add a message similar to the pop up blocked message at the top of the page whenever an image not from originating server is blocked. If the user says don't show this message again under options then show an icon on the status bar. I like to have this setting turned on because it blocks a lot of ads and other junk I don't want to see, but I did once forget it was on and got really confused when an image I was expecting to see didn't load, but if there had been an icon reminding me then it would not have been a problem.
One thing that is confusing is that not only do we forget that an image from a blocked server is, in fact, blocked, but we have to right click on an INVISIBLE image placeholder to unblock it, unless we go into the options menus and remove that server from the list manually. My idea would be to place a dynamically appearing menu somewhere immediately accessible when images are blocked (whether that be on the taskbar as an icon or whether that be a part of a yellow drop down indicator at the top, or something else) that lists these servers from which images are blocked on the current page, and place checkmarks next to each.
Comment 8•19 years ago
|
||
(In reply to comment #7) > One thing that is confusing is that... we have to right click on an INVISIBLE > image placeholder to unblock it This seems to have been fixed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-ZA; rv:1.8b2) Gecko/20050610 Firefox/1.0+ that is: a visible place holder is shown including alt text if available otherwise broken image icon
Comment 9•19 years ago
|
||
(In reply to comment #6) > I think you should leave the option there but add a message similar to the pop > up blocked message at the top of the page whenever an image not from originating > server is blocked.... I agree. I don't want to lose the UI for it. But there should be something to notify the user of its implications.
Comment 10•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+ ID:2005061804 I'm all for removing this useless option too. OK so it's not entirely useless, but it's not the kind of option an average user should be able to fiddle with so easily; it is responsible for sooo many tech support questions. (People seem to have an idea that if they want the most out of their browser, then all options should be ticked, which in this case actually makes some web-sites loose pictures). IMO the 'for the originating site only' UI should be removed. Such behaviour should be set via an about:config option, or an extension if an UI is required.
Comment 11•19 years ago
|
||
If not removing the UI, at least switch around the checkbox to mean the opposite of what it means now. I bet a lot of users go in, see the default 6 checkboxes checked and one not, and figure the unchecked one should be like the others.
Comment 12•19 years ago
|
||
Just a quick question, would removing the user interface also include about:config? I find having the option useful for, maybe, 15-25% of ads, depending on the mindset of wherever one surfs. It could only get better by preventing iframes from other sites from being displayed! That'd kill off another 30-40% easy! Anyhow, back on subject, I think the problem is the attempt to manage media in one or two checkmarks. It seems the problem maybe that the simplicity is confusing. There may be sites where users want everything to come in, wherever it comes from (like yahoo, for example), while others would only want or need some small specific outside bit. It has been a long time since internet sites have been uniform and predictable. You can't stop flash from making a pop up, and some sites will depend on flash (movie sites) while others use it for games only, and too many others use it for advertisements. IFrames, in some sites, are used to show previews, search results, a forum page or, now in too many cases also, an advertisement (ironically, getting around the originating site only thing). Needless to say, images from elsewhere serve the same purpose. You know the difference between images.foo.bar and ads.bar.foo, but a simple originating server option doesn't. Maybe that'll just be something we'll leave for Mozilla 2.0 engineers when it comes out in five years.
Reporter | ||
Comment 13•19 years ago
|
||
As it stands right now, this bug covers only removing the UI for it, not the underlying about:config option.
Updated•19 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 14•19 years ago
|
||
Below is a (probably incomplete) list of bugs filed on this issue since this bug was filed (2005-03-24). bug 287577 bug 291424 bug 292565 bug 293672 bug 294301 bug 295710 bug 296727 bug 296784 bug 298182 bug 299511 bug 303411 bug 304030 bug 304756
Comment 15•19 years ago
|
||
In addition to the regular bugreports about images not appearing on bugzilla, you also have to consider that this option causes problems for the affected websites, too. The support team for my company's website for example had at least 500 support requests the last 6 months from Firefox users, who accidently activated the option and then thought our website was "broken" because the images were missing. This might not be a large problem for Ebay and the likes, but it is a real problem for smaller ecommerce sites. The UI option should really be removed soon or at least there should be some "Warning - images could completely stop showing up on many websites" message when a user activates it.
Assignee | ||
Comment 16•19 years ago
|
||
Remove the UI for the pref. Note that the reason there were many problems with this going from <1.0 -> 1.0 was that the pref name changed, that shouldn't be a factor going from 1.0 -> 1.5.
Updated•19 years ago
|
Attachment #197650 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 17•19 years ago
|
||
Trunk: mozilla/browser/components/preferences/content.js; new revision: 1.12; mozilla/browser/components/preferences/content.xul; new revision: 1.14; mozilla/browser/locales/en-US/chrome/browser/preferences/content.dtd; new revision: 1.5;
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox1.5
Assignee | ||
Updated•19 years ago
|
Attachment #197650 -
Flags: approval1.8b5?
Comment 18•19 years ago
|
||
What is the about:config name for this preference? I don't see it in previous versions of Firefox or in the patch.
Assignee | ||
Comment 19•19 years ago
|
||
The pref is "permissions.default.image", see http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/all.js#692
Comment 20•19 years ago
|
||
Comment on attachment 197650 [details] [diff] [review] patch clearing until we get a patch with pref migration
Attachment #197650 -
Flags: approval1.8b5?
Assignee | ||
Comment 21•19 years ago
|
||
How do you propose handling the migration issue? ifdef nsContentBlocker.cpp? As you mentioned earlier, SM and other consumers might not want this pref clobbered.
Assignee | ||
Comment 22•19 years ago
|
||
Handle pref migration ourselves, don't migrate "from the originating site only".
Attachment #198262 -
Flags: review?(mconnor)
Updated•19 years ago
|
Flags: blocking1.8rc1?
Comment 23•19 years ago
|
||
not going to block the release on this.
Flags: blocking1.8rc1? → blocking1.8rc1-
Comment 24•19 years ago
|
||
Is this going to be removed from Firefox 1.5?
Assignee | ||
Updated•19 years ago
|
Target Milestone: Firefox1.5 → Firefox1.6-
Updated•19 years ago
|
Flags: blocking-aviary2?
Updated•19 years ago
|
Attachment #198262 -
Flags: review?(mconnor) → review+
Comment 25•19 years ago
|
||
Comment on attachment 198262 [details] [diff] [review] pref migration grr, wrong tab, hold on a sec
Attachment #198262 -
Flags: review+ → review?(mconnor)
Comment 26•18 years ago
|
||
Comment on attachment 198262 [details] [diff] [review] pref migration this is probably going to break now that we've shipped 1.5, since we didn't migrate/clear it then, so users who changed after after updating will revert to 1.0 settings. ah well...
Attachment #198262 -
Flags: review?(mconnor) → review-
Comment 27•18 years ago
|
||
not a blocker, but it'll end up in Fx2
Flags: blocking-firefox2? → blocking-firefox2-
Assignee | ||
Updated•18 years ago
|
Whiteboard: [checkin needed (1.8 branch)]
Updated•18 years ago
|
Whiteboard: [checkin needed (1.8 branch)] → [branch approval and pref migration needed]
Assignee | ||
Comment 28•18 years ago
|
||
Steffen: why did you change the status whiteboard? Why is a preference migration patch needed? I got approval from mconnor to land this, I just haven't done it yet.
Comment 29•18 years ago
|
||
Sorry, I should've added a comment. With pref migration I didn't mean migration from network.image.imageBehavior to permissions.default.image, since that is already migrated by http://lxr.mozilla.org/mozilla1.8/source/extensions/permissions/nsContentBlocker.cpp#93. But users who have enabled "for the originating web site only" in Firefox 1.0/1.5 can't easily disable this in 2.0 this since you're about to remove the UI. Workaround is to disable "Load Images", enable it again, and click OK, but who's going to find that out? We should migrate permissions.default.image from 3 (restricted) to 1 (enabled) IMHO. I didn't know mconnor already gave approval.
Whiteboard: [branch approval and pref migration needed] → pref migration needed?
Comment 30•18 years ago
|
||
If this is to make v2, someone needs to write a branch patch for it.
Target Milestone: Firefox 2 → Firefox 3 alpha1
Assignee | ||
Updated•18 years ago
|
Whiteboard: pref migration needed?
Target Milestone: Firefox 3 alpha1 → Firefox 2 beta1
Version: Trunk → 2.0 Branch
Assignee | ||
Comment 31•18 years ago
|
||
This will require the use of about:config for people who enabled the "from the original site only" pref in 1.5 or earlier and want to disable it in 2.0. I don't know whether that deserves anything more than a mention in the release notes: I think the users of that pref are very rare, which is why we're removing this UI in the first place.
Attachment #223575 -
Flags: approval-branch-1.8.1?(mconnor)
Updated•18 years ago
|
Attachment #223575 -
Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
Assignee | ||
Updated•18 years ago
|
Whiteboard: [checkin needed (1.8 branch)]
Assignee | ||
Comment 32•18 years ago
|
||
mozilla/browser/components/preferences/content.js 1.9.2.3 mozilla/browser/locales/en-US/chrome/browser/preferences/content.dtd 1.4.2.2 mozilla/browser/components/preferences/content.xul 1.11.2.4
Keywords: fixed1.8.1
Whiteboard: [checkin needed (1.8 branch)]
Comment 33•18 years ago
|
||
(In reply to comment #31) > Created an attachment (id=223575) [edit] > branch patch > > This will require the use of about:config for people who enabled the "from the > original site only" pref in 1.5 or earlier and want to disable it in 2.0. I > don't know whether that deserves anything more than a mention in the release > notes: I think the users of that pref are very rare, which is why we're > removing this UI in the first place. Why would you assume it is "rare" for users to understand this option and to use it? I have been using this option from as far back as I can recall. I had no problems understanding it. I have Fx 2.0 beta1 installed on a virtual machine. I was unable to view an image at the Kaspersky forum earlier this evening. I checked to see where the image was located and it was a safe site so I then opened options in Fx and intended to TEMPORARILY uncheck the option "from the orginal site only" so I could view this image and then I would recheck the box. To my utter surprise, there was no box and no option! Yet 2.0 was behaving as though I had the option checked. That really puzzled me. I asked about it in the Mozilla forum at dslreports and was led to this bug. Most everyone I know who uses Fx has this option checked and understands the option. Any sites they wish to have excluded are added in exclusions. It is not at all difficult to understand this option and it provides better security. For instance, I would never allow an image from ImageShack but I have i.dslreports. com in the exclusions as I trust that site's off site images to be safe. I do not want to go into about:config and change my "legacy" default of having this now invisible option checked. What I want and need is a way to easily uncheck the option when needed and recheck afterwards. Further, the exceptions box is now extremely confusing in 2.0. It says that I can allow certain sites to load images by placing them in the exceptions list. How could I do that if any site, not just the originating, can already load images because you have removed the option? Fx should have as its goal to have an outstanding browser not have as its goal to cater to the lowest, most ignorant web user. That is what IE does. Fx will become just another IE if this is its goal and removing this option box because ignorant users don't understand it puts Fx on the short list to become just another lousy IE type browser. It is extremely disappointing to those of us who have been with Fx from Phoenix days to see this happening.
Comment 34•18 years ago
|
||
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
Comment 35•18 years ago
|
||
I think it was a BIG mistake to remove the UI for this setting. The optimal use for me was to disallow loading remote images, then allow site specific remotes by adding them to the image manager. To make matters worse, FF does not have a right menu item for "allow images from ...". It assumes the user will only use the 'allow all images' setting and then provides a right menu item for "block images from ...". Also, why doesn't the image manager allow use of wildcards? When ebay uses perhaps 20 different image servers, like i12.ebayimg.com, why can't FF or SM allow adding just "*.ebayimg.com" instead of requiring 20 individual remote server hostnames? My primary rule settings are: 1] allow site images 2] deny remote images 3] allow specific remote images 4] block certain site images obviously, changing 1 or 2 will affect the usefulness of settings 3 and 4, but for me, that is the optimal configuration.
Assignee | ||
Comment 36•18 years ago
|
||
(In reply to comment #35) > Also, why doesn't the image manager allow use of wildcards? When ebay uses > perhaps 20 different image servers, like i12.ebayimg.com, why can't FF or SM > allow adding just "*.ebayimg.com" instead of requiring 20 individual remote > server hostnames? Allowing ebayimg.com will also allow all of its subdomains, so you don't need to list them all individually.
Comment 37•18 years ago
|
||
(In reply to comment #36) > (In reply to comment #35) > > Also, why doesn't the image manager allow use of wildcards? When ebay uses > > perhaps 20 different image servers, like i12.ebayimg.com, why can't FF or SM > > allow adding just "*.ebayimg.com" instead of requiring 20 individual remote > > server hostnames? > > Allowing ebayimg.com will also allow all of its subdomains, so you don't need > to list them all individually. > Thank you for that headsup. I tried being a little more specific like "*.ebayimg.com" and "*.images-amazon.com" but they failed to work. Supporting wildcards is still needed I think. consider ads10.xyz.com and img12.xyz.com. adding "xyz.com" would allow all. but with wildcard support I could allow img*.xyz.com and still block ads*.xyz.com
You need to log in
before you can comment on or make changes to this bug.
Description
•