Open Bug 64068 Opened 24 years ago Updated 1 year ago

Set Image blocking (preferences) doesn't work for local drives!

Categories

(Core :: Graphics: Image Blocking, defect, P3)

Product:
Core
Component:
Graphics: Image Blocking
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: bugs4hj, Unassigned)

References

Details

Mozilla Build  : 2000122920 on WinNT 4 sp6b.
Current result : images keep loading.
Expected result: no images loaded at all.
Path to follow : Edit/Preferences/Advanced/Images/Do no load any images

Please make a small HTML file with an <img src="c:\foo\bar.gif"> tag on your
local drive to test this.
over to cookies component.
Assignee: asa → morse
Status: UNCONFIRMED → NEW
Component: Browser-General → Cookies
Ever confirmed: true
QA Contact: doronr → tever
Selective image blocking is done in the nsCookies.cpp file and so would get 
classified as a cookie bug.  Total image blocking is done in the image library.  
This bug involves total image blocking, so reassigning.
Assignee: morse → pnunn
Component: Cookies → ImageLib
QA Contact: tever → tpreston
Morse, may I ask for 'selective' image blocking also, or do I have to file a new
bug for that one?

You may ask yourself: 'Why in the world would somebody use a local drive in the
first place?" To clarify, I'm using Xdrive (x:) a lot to store Mozilla bug's, in
a more save place, my son took of all the file's in his attempt to clean up the
drive!! (excluded from backup). And so when I'm in my Hotel room (5 months a
year!!), I can use my notebook to work on those files.

Steve:
Aren't you handling all image blocking now?
-p
Assignee: pnunn → morse
I didn't think I was.  But if I am, this won't get done for quite a while.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
I'll take it back for now.
-p
Assignee: morse → pnunn
Status: ASSIGNED → NEW
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Target Milestone: mozilla1.2 → Future
changing status to [imglib]
Whiteboard: [imglib]
over to image blocking
Assignee: pavlov → morse
Component: ImageLib → Image Blocking
QA Contact: tpreston → tever
Whiteboard: [imglib]
Target Milestone: Future → ---
Maybe this is not a dupe, but I think there is some significant overlap between
this bug and Bug 133114.  Perhaps this bug depends on that one (since the fix
for "Do Not Load Any Images" behavior being ignored for local pages may also fix
this one)?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
Somebody please verify, this one looks like a dup of bug 51266 for me.
Yeah, I'm going to have to agree that Bug 51266 and this bug are one in the same.
*** Bug 133114 has been marked as a duplicate of this bug. ***
This bug should not be duped to bug 133114 unless this bug has OS and platform
changed accordingly. All that detail in the other bug may be useful to the
developers. This one has little helpful detail.

Bug 133114's focus is on the parallel to 4xp, that is, in 4xp we simply
disallowed all images from automatically loading until hitting the images button
in the main menu.

Here in Mozilla we have set up rules for allowing/disallowing image loading
according to origin, and we don't even have a load images button. It really is
not the same thing, although the fix for both might probably involve a single
patch. Maybe bug 133114 should left open and depends on this.
Priority: -- → P3
Target Milestone: mozilla1.2beta → mozilla1.2alpha
OS: Windows NT → All
Hardware: PC → All
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
*** Bug 160751 has been marked as a duplicate of this bug. ***
*** Bug 159471 has been marked as a duplicate of this bug. ***
*** Bug 178301 has been marked as a duplicate of this bug. ***
Mass reassigning of Image manager bugs to mstoltz@netscape.com, and futuring.
Most of these bugs are enhancement requests or are otherwise low priority at
this time.
Assignee: morse → mstoltz
Status: ASSIGNED → NEW
Target Milestone: mozilla1.3alpha → Future
I don't know if either of these two issues deserves filing a new bug
so I'm listing them here, since I believe they are related to
this bug:

1) When "load images" is disabled, remote images referenced
from a local page are loaded.  For example, take an HTML
file stored on a local hard drive with the image link
<IMG SRC="http://www.server.com/image.gif"> in
it, and the image will load even if images are disabled.

2) Images loaded through CSS are always loaded (even on remote
pages) regardless of the image loading preference.  For example,
assign an image via list-style-image and it'll ignore the
preference and load.

The first point sounds like it's covered here (though if that's true, priority
should be updated).

The second is definitely a seperate issue. If there isn't a bug for that yet,
you should add one.
QA Contact: tever → nobody
Does anyone still see this? For me, when I set the preferences to never show any
image, I don't see an image when loaded with file:// (linux build, recent cvs)

As far as I know, the PAGE has to be local, it doesn't matter
whether or not the image is local.

I'm still seeing this, myself.  I always edit my sites locally
(I edit with a text editor then preview in Mozilla) and all
images always load when I'm previewing off the hard drive.

Mozilla 1.3
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

Can you try with a recent nightly? There have been a lot of changes in this
area. thanks.
Verified with build 2003042808 (Win32).  Images on local pages no longer
load for me if image loading is disabled.  (Additionally, using
"originating server only" will allow local images to load on local pages,
but not remote images on local pages, which is the behavior that I'd expect.)
There are still issues related to disabling image loading (such as
images are displayed as if the page was being rendered in "standards
mode" even if View -> Page Info claims the page is in "quirks mode")
but I think those are being handled in other bugs.  So, for the
purposes of this bug, I think we can close it as "fixed."

> Images on local pages no longer load for me if image loading is disabled.

That sounds logical to me. you say that you don't want to load images, so the
loading of images is disabled.
Erm, sorry about that. You misunderstood. Read the last line of my
previous post again. :)  I'm saying it's working the way it should
now (more or less) so probably this bug can be closed as "fixed."

Ok, i misunderstood. Resolving as worksforme. It must have been one of the
checkins to this area, but don't know exactly which :)
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
Regression:  This is broken again as of Mozilla 1.4.
I did make sure to restart the browser after turning off image
loading, just to be sure (since changing the preference without
restarting has been known to cause problems in the past).

Remote images no longer ignore the preference like before.  Only
local images on local pages do.

Yes, I am seeing this as described above for Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.6a) Gecko/20031024 Firebird/0.7+ -- to restate it, remote
images on local pages do not load (OK), but local images still load (not OK). 
Can't see this as being a very big deal, but something _is_ broken.  Reporter,
are you able to change the status to "REOPENED"?  (I am not able to do this.)
At
http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsImgManager.cpp#132
we explicitly check only http or https, other protocols are always allowed to
load images.
Related: bug 203940.
I don't think developers really mean to restrict blanket OR selective image
blocking to those images loaded with http/https/ftp protocol.  Obviously, this
bug is still manifest (for example, Firebird nightly trunk 20031105) and should
really be reopened.  Is there another reason it hasn't yet?  (I guess there's
always the fact that people are busy.)
I don't file bugs that can be resolved as WORKSFORME, not even after a long
period of time so I am reopening per comment #29
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I should note that I have discovered that firebird (and Moz?) seems to have the
ability to allow images of schema:file (i.e., to allow file: images to be loaded
regardless of whether image loading is turned off).  I was not aware that this
possibility even existed, and I had apparently unwittingly set the rule "allow
schema:file" in my image permissions (not sure how this happened), so I thought
my previous confirmations might have been wrong.  But apparently not.
I tested -- with a new profile, with no rules under image permissions -- and I
still see the problem of local images loading in local documents when image
loading is turned off (i.e., the originally reported bug).  [As a side note, if
there was ever a problem with remote images being loaded in local pages with
image loading turned off, as mentioned in Comment 22, I do not find that to be
an issue now -- just file: images in file: documents.]
So the bug is still there, and I'm glad it's been reopened.  I hope Comment 30
was not an attempt to suggest that this bug should be marked invalid (after all,
it's been open for nearly 3 years and no one has said it's a wontfix yet).  I
would say there is a workaround in right clicking on a file: image and choosing
"Block images from  " in Firebird (not sure about Moz); but unfortunately, this
appears to fail as well.
By the way, now that this bug has been reopened could someone look at marking
Bug 223460 a duplicate of this bug?  It seems to cover the same problem.
*** Bug 223460 has been marked as a duplicate of this bug. ***
This bug is important to web page developers. If one cannot review the
appearance of a local page with images off, then the rendition of ALT tags
cannot be determined without first uploading the pages to a server.
*** Bug 303731 has been marked as a duplicate of this bug. ***
*** Bug 357746 has been marked as a duplicate of this bug. ***
Assignee: security-bugs → nobody
Status: REOPENED → NEW
I'm using FF 2.0.0.14 on Win XP, and this bug is still open. I'm having trouble developing for images-off Firefox users because of this.

This bug has been open for almost 7 years, 4 months. It's not really a blocker, but this is a pretty basic option.

How hard would it be to fix this sucker? For example, are there a bunch of dependencies that need to be looked at, or can this be fixed independently?
QA Contact: nobody → image-blocking
Now in 2012, I just wanted to mention:
Local images are always loaded, despite unselecting "Load Images Automatically"

One might think in Preferences that unselecting
"Load Images Automatically" always works, but if one browses a local
file, e.g., 
file:///home/jidanni/jidanni.org/location/directions/zaokeng.html
and that page includes e.g.,
<img width="[Image: 燥坑枝45ElecPole 至 to 目的地 GOALs]" src="zaokengzhi48.jpg">
then forget about seeing that alt code, as you are going to be seeing
the image like it or not!
So as we see in Bug 709611, there are several finer categories of images that could be listed for the user to checkmark.

One might say the average user shouldn't be so picky, but then again the average user wouldn't be blocking images in the first place.
There, in the Exceptions sub list, one could put "Load [x]local images [x]images coded right into the page" etc.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates.
:aosmond, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(aosmond)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(aosmond)

(In reply to Release mgmt bot (nomail) [:suhaib / :marco/ :calixte] from comment #44)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

this very old bug is still relevant, Thunderbird 102.5.1x64 @t Win11.
a use case when it happens: download web page containing images with browser, open it's local copy in it, select all and paste into new message in Thunderbird.
you have to unblock each image manually to include it into your message.

there should be no local resource(images) blocking on new message creation.

p.s. wow, 22-уеаrs old bug! humans are allowed to have guns at this age;)))

You need to log in before you can comment on or make changes to this bug.