Closed Bug 310420 Opened 19 years ago Closed 12 years ago

when I choose to "Do not load any images" - images are still loads by browser. seems like this option is not working

Categories

(Core :: Graphics: Image Blocking, defect)

Product:
Core
Component:
Graphics: Image Blocking
Version:
1.8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: forgarbage, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050217

When I choose radio button: 
Edit->Preferences->Privacy & Security->Images->Image acceptance policy->"Do not
load any images"
Images on pages are still present and browser loads and shows all images.

Windows XP SP2 with latest updates

Reproducible: Always

Steps to Reproduce:
1.Edit->Preferences->Privacy & Security->Images->Image acceptance policy->"Do
not load any images"
2. Open page with images

Actual Results:  
Images will be still loaded and showed.

Expected Results:  
Images should not be loaded.
Version: unspecified → 1.8 Branch
Can you try in a recent SeaMonkey build.  Your build is rather old for bug reports.
(In reply to comment #1)
> Can you try in a recent SeaMonkey build.  Your build is rather old for bug
reports.

Sorry, I don't understand why I should use SeaMonkey insted of Mozilla 1.8? Or
SeaMonkey is next generation of Mozilla 1.8 branch ? If so, why Mozilla 1.8 is
still downloadable and has betta 1 status (but SeaMonkey is 1.0Alpha)?
(In reply to comment #2)
> Sorry, I don't understand why I should use SeaMonkey insted of Mozilla 1.8? Or
> SeaMonkey is next generation of Mozilla 1.8 branch ? If so, why Mozilla 1.8 is
> still downloadable and has betta 1 status (but SeaMonkey is 1.0Alpha)?

1) Yes, SeaMonkey is the new version of the Suite.
2) Don't know.

The point is that you're using an old build and that you need to test with a
newer one to see if this is still a bug.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050930 SeaMonkey/1.1a

Images block correctly.
SeaMonkey is 1.0a is 1.0 because it's the first version and alpha because it's
the first milestone.

==> image blocking
Assignee: general → security-bugs
Component: General → Image Blocking
Product: Mozilla Application Suite → Core
QA Contact: general
Alex, Mozilla Suite 1.8 was axed.  It's never going to ship.

Seamonkey is based on the same code, and it's in alpha because the powers that be made major changes to back end code after the Mozilla 1.8 betas (changes that took the code back to alpha).

Do you still see the bug in a recent Seamonkey 1.0a or trunk build?
Assignee: security-bugs → nobody
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1

I see this when I set "Do not load any images" and I go to <http://finance.yahoo.com/p?v&k=pf_1>.  That URL is for a logon page, but you don't have to logon.  The Yahoo logo is visible at the top of that logon page.  
Interesting.  With a 1.8 branch Seamonkey build, I can't reproduce using the steps in comment 7...
Perhaps it's something in my configuration or preferences.  My configuration includes:  
Windows XP Home Edition 5.1.2600 Service Pack 2 Build 2600
800x600 screen, 32-bit true colors
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 
   SeaMonkey/1.1.1
with Menu, Navigation, Status, and PrefBar bars displayed
Cookies for the originating Web site only (allow session cookies from yahoo.com, 
   no stored cookies from any Yahoo domain at the time of the problem)
No firewall or proxy
Java J2SE RE v.6 (build 1.6.0-b105, file and product versions 6.0.0.105)
Flash 9.0 r28 (but blocked with Flash Blocker)
Extensions:
PrefBar 3.3.4:
	Unrequested popups suppressed
	No images (in this case but not my usual setup)
	Flash Blocker enabled 
	etc
FlashBlock 1.3.5
Mnenhy 0.7.5
Hmm... Does this happen without the extensions?
Before I try to remove the extensions (all of which are installed in the SeaMonkey root and not in my profiles), consider the following:  

Neither Mneheny nor PrefBar have any effect on page rendering.  They should not contribute towards the problem.  

FlashBlock affects page rendering.  However, I see the problem even if I disable FlashBlock.  

(Please do not add me to the CC list.  I am tracking this bug, and I check all bugs that I'm tracking at least twice each week.  That's more often than I check my alternative mail boxes.)  
I'm just trying to figure out how your setup differs from mine is all...  I don't know enough about FlashBlock to tell you what effect disabling really has, e.g.
I created a new, test profile.  The only preferences I set were to hide the PrefBar toolbar and to set permissions.default.image to 2 (no images).  The problem went away.  

In all other respects, my usual profile is not "broken".  If you wish, I can post my prefs.js as an attachment.  

By the way, I think I may have been wrong about where FlashBlock is installed.  In the test profile, there was no evidence of that extension.  Thus, I believe it's installed in the profiles and not in the root.  I have a second, less used profile where the problem does not occur.  That profile has FlashBlock installed.  
I assume that if you reshow the PrefBar toolbar the problem still doesn't appear in the test profile?

And yes, if you want to post the prefs.js, or mail it to me, that would be nice.
The pref file I got in the mail has:

  user_pref("permissions.default.image", 3);

not 2...
My usual setting is 
         user_pref("permissions.default.image", 3);
which is "Accept images that come from the originating server only".  That was the preference setting in effect when I copied my prefs.js.  But that was not the setting when I saw the problem.  

I have a dial-up connection.  Recently, I began trying suppressing all images
         user_pref("permissions.default.image", 2);
when visiting certain Web sites in an attempt to speed their loading.  This generally works well.  

So far, the Yahoo site is the only one where I notice the problem in this bug report.  Thus, the problem might reside in the HTML of the page.  However, I would expect that suppressing all images would cause all <img> markups to be ignored.  The Yahoo page uses <img>.  

If you copy that prefs.js (with the changed permissions.default.image value) into a profile where the image blocking works, does it stop working?
I created a new profile "Image Blocker" in the same directory as my other profiles.  Although I'm running WindowsXP, the directory is [C:\WINDOWS\Application Data\Mozilla] and not the usual [C:\Documents and Settings\. . . ].  

In my standard profile "David", I set 
          user_pref("permissions.default.image", 2);
using PrefBar.  

I shut down SeaMonkey.  I then copied both prefs.js and user.js files from "David" to "Image Blocker".  I used the Profile Manager to launch SeaMonkey directly into "Image Blocker".  After going to [Edit > Preferences > Privacy & Security > Images] to verify that no images should be loaded, I then went to <http://finance.yahoo.com/p?v&k=pf_1>.  

The problem did not appear.   
OK.  So it's not prefs.js.  What else is different between the two profiles?  Do you have the site in question in your explicit image permissions lists?
Aha!  The image is from a different domain, for which I did give permission to load.  

Problem solved.  
Oh, wait a minute!  

If my preferences are set to "Do not load ANY images" [emphasis added], should not that override any white-listed domains?  

While we now know why I'm seeing images at the Yahoo login page, that does indicate a bug.  I believe the white list for images set by the Image Manager should not apply when
     user_pref("permissions.default.image", 2);
Instead, ALL images should be blocked.  

Further, when 
     user_pref("permissions.default.image", 1);
(display all images), it's possible the black list for images should not apply.  Instead, all images should be viewed.  I'm not really sure about this because a user might want to block some image sources even when otherwise viewing all images.  

However, it might be the case that the white and black lists should apply only when 
     user_pref("permissions.default.image", 3);
I think this is one of those situations that might best be resolved by polling current users.  
> If my preferences are set to "Do not load ANY images" [emphasis added], should
> not that override any white-listed domains?  

Dunno.  That's mvl's end of things.  ;)
iirc, the option to go the image manager was once named 'exceptions' (i don't have a seamonkey build right now to test what it is now). The image manager sets the exceptions to the default pref.
Anyway, for your problem there is a quite easy workaround: remove all the entries from the image manager. If we would change the code the way this bugs asks for, the current behavior can not be used anymore. There won't be a way to not load any images except a few your selected.
So, for me, this is a wontfix. It's designed the way it is now for a reason.
Same problem: Can't get rid of advertisement. Please refer to: 
http://dagskrain.is/auglysingar/korkur/?CategoryID=5&page=2&m=korkur&d=5&style=font2
for a test (URL on 2 lines). 

I tried disabling java script, telling it not to load images, disabling 
helper applications, blocking popups, nothing helps. Could not find 
"Disable java", where has that gone to? 

Please tell me how to view this page without the **** (or then maybe 
this time I really found a bug?)

Mariane
Mariane, you probbaly need to disable your Flash plug-in.

As for Java, the option is right there in Preferences > Content, right under the option to disable javascript.
Edit / Preferences / Advanced / Script and Plugins: Everything disabled
Edit / Preferences / Privacy & Sec / "Do not load any images"
Edit / Preferences / Browser / Helper App / "Always ask" for everything 
except for the ones which don't offer an "always ask" option. In this 
last case I chose "Wordpad" because Wordpad cannot display pictures, as 
far as I know. 

Did I forget something? 

I didn't reboot the computer since I made these changes, but I tried 
shift/reload and also to close and re-open SeaMonkey. (Now I'm posting 
with Firefox because SeaMonkey is next to unusable - but STILL this 
*** web site displays it's advertisements!) 

Have you tried to look at it and remove the ads? 

http://dagskrain.is/auglysingar/korkur/?CategoryID=5&page=2&m=korkur&d=5&style=font2
> Did I forget something? 

Yes, the Flash plug-in I told you to disable in comment 25.  Since you seem to be using a quite different browser from me (I'm using a Firefox trunk build on Mac), I can't tell you where to find that.  For me, it's under Tools > Add-Ons > Pugins, select the Flash plugin and click the Disable button.

In any case, that's not related to this bug; if you need user help with your browser the appropriate newsgroup or forum is a better idea.
Oooops. <face colour>red</face colour>
QA Contact: image-blocking
Hi,
Configuration:

Using FF 4 on Fedora 14 64 bit.
Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0) Gecko/20100101 Firefox/4.0
I have unchecked Preferences->Content->Load Image Automatically, Disabled Flash Plugin .

Problem:

I do not see any images while browsing sites, but if i do a search on google for say "Obama", I see the images in "Videos for Obama" "Images for Obama" in the main search results page.

Expected: I should see no images at all
That image is using a data: URI.  Those are excepted from the "load images" check, as are various other URIs that don't hit the network (file:// for example).
Hi,

Found some bugs that talk about this

https://bugzilla.mozilla.org/show_bug.cgi?id=501455
https://bugzilla.mozilla.org/show_bug.cgi?id=331257

This is unexpected behavior when I want a text only view of the site :P

Can I block the data uri by using preference  in about:config ?
Is something here left not covered by Bug 331257?
Whiteboard: closeme INCO 2012-10-01
Resolved per whiteboard.
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme INCO 2012-10-01
You need to log in before you can comment on or make changes to this bug.