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)

2.0 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2 beta1

People

(Reporter: ali, Assigned: Gavin)

References

Details

(Keywords: fixed1.8.1)

Attachments

(3 files)

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?
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.
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. 
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
(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).
Well lets see if we can get this on the radar before the 1.1 branch. 
Flags: blocking-aviary1.1?
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.
(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

(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.

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.
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. 
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.
As it stands right now, this bug covers only removing the UI for it, not the
underlying about:config option.
Flags: blocking-aviary1.1? → blocking-aviary1.1-
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
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.
Attached patch patchSplinter Review
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.
Assignee: mconnor → gavin.sharp
Status: NEW → ASSIGNED
Attachment #197650 - Flags: review?(mconnor)
Attachment #197650 - Flags: review?(mconnor) → review+
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
Attachment #197650 - Flags: approval1.8b5?
No longer blocks: 310271
What is the about:config name for this preference?

I don't see it in previous versions of Firefox or in the patch.
Comment on attachment 197650 [details] [diff] [review]
patch

clearing until we get a patch with pref migration
Attachment #197650 - Flags: approval1.8b5?
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.
Attached patch pref migrationSplinter Review
Handle pref migration ourselves, don't migrate "from the originating site
only".
Attachment #198262 - Flags: review?(mconnor)
Flags: blocking1.8rc1?
not going to block the release on this.
Flags: blocking1.8rc1? → blocking1.8rc1-
Is this going to be removed from Firefox 1.5?
Target Milestone: Firefox1.5 → Firefox1.6-
Flags: blocking-aviary2?
Attachment #198262 - Flags: review?(mconnor) → review+
Comment on attachment 198262 [details] [diff] [review]
pref migration

grr, wrong tab, hold on a sec
Attachment #198262 - Flags: review+ → review?(mconnor)
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-
not a blocker, but it'll end up in Fx2
Flags: blocking-firefox2? → blocking-firefox2-
Whiteboard: [checkin needed (1.8 branch)]
Whiteboard: [checkin needed (1.8 branch)] → [branch approval and pref migration needed]
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.
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?
If this is to make v2, someone needs to write a branch patch for it.
Target Milestone: Firefox 2 → Firefox 3 alpha1
Whiteboard: pref migration needed?
Target Milestone: Firefox 3 alpha1 → Firefox 2 beta1
Version: Trunk → 2.0 Branch
Attached patch branch patchSplinter Review
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)
Attachment #223575 - Flags: approval-branch-1.8.1?(mconnor) → approval-branch-1.8.1+
Whiteboard: [checkin needed (1.8 branch)]
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)]
(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.




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
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.
(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.
(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.

Attachment

General

Created:
Updated:
Size: