851701 - Remove "Load images automatically" checkbox from Prefs

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

Turning off image loading in Firefox will make the browser unusable on many sites. We should remove it from the preference panel, and restore any non-default setting on upgrade to ensure that people get a usable browser again.

Comment 1

[Mardeg]

How will "restore any non-default setting" affect people using the "Exceptions" as a whitelist to control bandwidth costs?

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Those people should probably migrate to something like adblockplus.

Comment 3

[Mark Straver]

AdBlockPlus and similar is very selective. People who use this option are usually NOT using it to block ads (the times I've used this option it has been for anything but that, but rather to reduce bandwidth overall to ONLY get text responses on very poor connections or pay-per-byte mobile/satellite schemes).

Comment 4

[Jesse Ruderman]

Will the per-site setting remain?  (Oddly, it's in Page Info > Permissions but not in about:permissions.)

Comment 5

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, this Option (being turned off) caused bad Experiences on certain Sites in the Past:
e.g. Bug 588742 / Bug 787811.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to Jesse Ruderman from comment #4)
> Will the per-site setting remain?

I think we should remove it -- things like AdBlock are better suited and have better UI for list management.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to Mark Straver from comment #3)
> AdBlockPlus and similar is very selective.

Specific add-on implementations aside, my point was that this wasn't something that Firefox proper should support. A simple add-on that just re-adds the checkbox could be made too :)

(In reply to Justin Dolske [:Dolske] from comment #6)
> (In reply to Jesse Ruderman from comment #4)
> > Will the per-site setting remain?
> 
> I think we should remove it -- things like AdBlock are better suited and
> have better UI for list management.

I concur, but I think that's best left to a separate bug.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This checkbox is pretty useful to me as both a Gecko developer and website developer.

Would it make sense to move it into developer tools or something along those lines?

Comment 9

[John Drinkwater (:beta)]

(In reply to Boris Zbarsky (:bz) from comment #8)
> Would it make sense to move it into developer tools or something along those
> lines?

Very much so, its a handy tool to find what could be broken if a cdn is down.

Comment 10

[John Drinkwater (:beta)]

Filed Bug 852490 for adding them to web dev tools.

Comment 11

[Gervase Markham [:gerv]]

Limi is right. Kill this UI. (And add to web dev tools.)

Gerv

Comment 12

[:Gijs (he/him)]

Attachment: Patch, part 1 of ? - remove UI

So this is the dumb part of simply removing the UI and strings. I've done both the current and in-content prefs stuff, as I presume we don't really want this "accidentally" popping up again if/when we do shift to in-content prefs. R? for dolske because... because. If it's better to pick someone else, please reassign the review to them. :-)

What else needs to actually happen? There seem to be 3 things that people are concerned about:
1. Reset people's preferences if they are somehow non-default and "broken", or if they're in use but not broken, alert the users that the UI has gone away.
2. The use of these preferences for bandwidth-usage-containment
3. The use of these preferences for development reasons

For 1, in what exact cases, if any, do we want to do something? (How) do we inform the user? What options for change/recovery/add-ons should we give them? Is there precedent I can look at?

For 2, even if ABP is perhaps not an ideal choice, aren't there other add-ons users can look at? It is trivial to create an add-on that puts these items back (essentially, the reverse of this patch using XUL overlays and a separate bit of l10n). I'm happy to do that if people think it is necessary, but I suspect more sophisticated ones are already available.

I think 3 is now covered by bug 852490; I'm sure the devtools folks will be happy to pick that up.

(for 1 and 2, setting needinfo to limi)

Comment 13

[:Gavin Sharp [email: [e-mail]]]

For 1), I think we should just revert the pref to its default value in nsBrowserGlue's _migrateUI, and leave it at that.

I don't think we need to do anything to address 2) at all (having a list of add-ons that offer similar functionality for people who will ask would be useful - creating one yourself is probably not a worthy endeavor).

Comment 14

[:Gijs (he/him)]

Attachment: Remove UI

Didn't notice that the exceptions label wasn't actually reused for the other buttons; removing that too.

Comment 16

[Dão Gottwald [:dao]]

FWIW, I used this option once when I used my phone's connection (which has a 1gb-per-month limit) on my laptop, but since this was an uncommon scenario for me, I wouldn't have had an add-on ready for that nor would I have known about the hidden pref (except that I would have known about it given my Mozilla specific expertise).

I just checked IE and Chrome, both of them expose this option buried somewhere in advanced option sections.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 733775 [details] [diff] [review]
Remove UI

Seems like we could un-generic-ify _showExceptions/remove _exceptionsParams now that there's only one caller.

r=me with or without that (maybe file a followup if you don't want to do it here)

Comment 18

[Justin Dolske [:Dolske]]

I hear bandwidth/cost concerns frequently mentioned in conjunction with this pref. I think that's a valid use-case, but that this pref is exceptionally poor at serving it.

Filed bug 859998 on the general issue of having a better experience on low/expensive bandwidth connections.

Comment 19

[:Gijs (he/him)]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #17)
> Comment on attachment 733775 [details] [diff] [review]
> Remove UI
> 
> Seems like we could un-generic-ify _showExceptions/remove _exceptionsParams
> now that there's only one caller.
> 
> r=me with or without that (maybe file a followup if you don't want to do it
> here)

Checked into inbound:

https://hg.mozilla.org/integration/mozilla-inbound/rev/b61950280061

and filed bug 860033 for the un-generic-ifying.

Comment 20

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b61950280061
https://hg.mozilla.org/mozilla-central/rev/bcaa26984f9a

Comment 21

[:Gijs (he/him)]

Setting user-doc-needed for https://support.mozilla.org/en-US/kb/settings-fonts-languages-pop-ups-javascript#w_content-settings (probably a good idea to update in one go for bug 851702 which landed pretty much simultaneously).

Comment 22

[Félix]

Excuse my English, my native language is Spanish.
The option "Load images automatically" is very effective for saving bandwidth.
I have a maximum download speed of 24KBytes/s and an average speed of 1-4KBytes/s, for me it means the difference between surfing or not.
In my experience, almost always I navigate without images, in very few sites you can not navigate without images and it is because they are poorly designed, all links, menus, etc.. are images, do not even have the tags 'title' or 'alt'.
I use ABP, blocking audio/video HTML5, flash blocking, disable speculative loading/prefetching to control bandwidth. The use of ABP for this is just too uncomfortable.
I agree to change it to the developer tools but not eliminate it.
I use QuickImage (https://addons.mozilla.org/en-US/firefox/addon/quickimage) to quickly control this option.

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

This has been noted in the Aurora 23 release notes:

http://www.mozilla.org/en-US/firefox/23.0a2/auroranotes/

If you would like to make any changes or have questions/concerns please contact me directly.

Comment 24

[u279076]

Adding this to the sign-off criteria for Firefox 23.0b1.

Comment 25

[Mihaela Velimiroviciu (:mihaelav)]

Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130618 Firefox/23.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20130618 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130618 Firefox/23.0
Build ID: 20130618004018

Verified that the "Load images automatically" option is no longer available in Preferences/Options

Comment 26

[Jason]

Okay, I am now getting calls about this option being removed.

Can someone please give me an explanation of what harm this option was causing by existing?

I am almost stunned that it was removed.

Comment 27

[Mark Straver]

The general consensus seems to have been to add it to dev tools (comment 9, comment 11) which would have worked, but bug 852490 was marked WONTFIX and I sure can't find the option in dev tools or anywhere else now.

The last thing I want to have to do is find, download and install an add-on over an extremely slow and/or pay-per-byte connection just so I can switch off images. Having to direct stressed users to about:config to find the pref is probably not going to work very well ;P (and please don't tell me you plan to remove the actual pref as well...)

I agree that per-site blocking would be better served in a different way (through dev tools and what not), but having a global kill switch for images is what this is used for most, and should remain accessible at least somewhere in prefs.

Comment 28

[Jason]

I guess, from my point of view, it makes no sense to kill an option that already exists and that has already been programmed.  The actual work was already done.  I am just trying to figure out exactly what harm it was causing just by being there.

And nobody can really say that users can accidentally turn it on break their Web-browsing experience, either, because this option can be locked so that users cannot change it.

Was this an arbitrary decision made by a small group of people, or did most Firefox users actually want this change?

Comment 29

[:Gavin Sharp [email: [e-mail]]]

"the harm" was well described in the post I mentioned: it complicates the prefs UI and people can end up checking it accidentally, which makes their browser be not useful, and then they don't know how to fix things. That it can be locked in theory is not relevant, because it wasn't locked in practice.

I have no doubt there are plenty of anecdotes about how incredibly useful or essential this pref was, but the reality is that those anecdotes are not representative of our user base at large, and reflect a miniscule minority of actual use of Firefox. Firefox has a great add-on ecosystem and plenty of "under the hood" tweakability (about:config), so thankfully the few people who really need this use case addressed have plenty of options.

Comment 30

[Mark Straver]

Sorry if this is worded a little crudely, but it probably has to be said at this point:
I think the people randomly clicking options in preferences of which they don't know what they do and then not able to find them again after clicking OK is also not "representative of our user base at large". I don't know what the average IQ is you are catering to, but if it's assumed that low, then you should not make any preferences available at all.

Comment 31

[:Gavin Sharp [email: [e-mail]]]

It's not a matter of IQ, it's a matter of people having other things more important to worry about than figuring out out to configure their browser. You won't get very far in software development if you use words like "stupid" to describe your users.

To be clear, people accidentally disabling images is not the primary driver here; that's about as anecdotal as some of the "this preference is critical" counterpoints. The primary driver is a preference pane that is useful and not littered with useless options, and this change was one small step in that direction (bug 851698 tracks others).

Comment 32

[Mark Straver]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #31)
> You won't get very far in software development if you use words like
> "stupid" to describe your users.
Yet, that is exactly what the drivers behind these changes are doing, removing options from the preferences pane because otherwise "users will shoot themselves in the foot" is, in other words, calling users "stupid".

> To be clear, people accidentally disabling images is not the primary driver
...yet that has been given as the main argument for removing it.

> The primary driver is a preference pane that is useful and
> not littered with useless options.
Considering the indicated usage scenarios above and the reason why there is resistance to this removal (and people getting calls from users to help them with their preferences since they were removed from the pane), this option was far from useless, and certainly not "littering the preferences pane".

In the end, it is your product of course, and you can take it in whatever direction you wish. I just think you need to give things a bit more careful thought and look at usage scenarios and ping your users before blatantly removing options. 
I had no issue with the option being moved to a more obscure location like suggested initially (and agreed upon, which is why I stopped paying attention to this bug), but just dropping it was definitely taking something useful out of the UI.

Comment 33

[Nick]

I am compelled to chime in and express my great dismay to find this option removed from FF23. I figured it was moved to the Advanced tab but was shocked to see it completely eliminated.

Like countless others, I used this feature daily or at least weekly to streamline my web-browsing. I could explain why I used it, but others have done that enough. The idea that the devs would remove this simply because some people are too foolish to understand its purpose...I honestly find that insulting. So I'm being punished because of the incompetence of others?

Frankly, (pardon my strong feelings) forcibly removing features is what I'd expect from Microsoft (see Windows 8) or a closed-ecosystem like iOS. I use Firefox precisely because it let's me browse how I see fit.

I realize I can do the manual config or download some add-on, but as others have said, that's one more step we must take to fix something that should have never been removed. I am a VERY strong believer in empowering your users rather than sheltering them.

I agree with Mark Straver that this move seems to be fairly ill-considered and reduces the "out-of-the-box" usefulness of Firefox. Please add the option back. Regardless, thank you for all your hard work on Firefox. Thank you for your time.

Comment 34

[Christopher Booth]

This has to be the stupidest 'bug fix' ever proposed and immediately needs to be reversed in the next release, or as soon as possible. Only morons create websites that are not accessible to the blind and have no useful content with images turned off. I regularly turn off images to see what the alt tags are. In the meantime, even though I have been a loyal Firefox user for years, I have switched to Google Chrome, which still allows turning off loading images and turning off javascript, the second stupidest 'bug fix' ever proposed. Both options need to be restored immediately, and when they are (not as a work around add-on, but for everyone), I will happily return to using Firefox.

Comment 35

[Jason]

I agree that this needs to be reversed.  Perhaps someone could introduce a big fix to get it put back?  I mean, the fact that it's missing is far more of a bug than its mere existence ever was.

This week has been horrible.  We have had to explain to users that it was not US in IT who removed the option.  Like most people, they cannot believe an option has been unnecessarily removed.

Comment 36

[Christopher Booth]

For anyone in IT, I recommend doing exactly what I did, uninstall 23, reinstall 22, and uncheck the box install new updates automatically.

Comment 37

[:Gavin Sharp [email: [e-mail]]]

https://addons.mozilla.org/en-us/firefox/addon/image-block/ is a better alternative for blocking images selectively than our preferences UI was.

Using and refusing to update old versions of Firefox can leave you vulnerable to serious security issues, and is not recommended.

Bugzilla is not meant as a discussion forum, I'm going to restrict further comments on this bug. Reports of new issues belong in new bug reports, and reasoned discussion and constructive criticism belongs on firefox-dev (https://wiki.mozilla.org/Firefox/firefox-dev).