Closed Bug 133114 Opened 22 years ago Closed 22 years ago

"Do Not Load Any Images" Behavior Ignored for Local Pages

Categories

(Core :: Graphics: Image Blocking, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 64068
mozilla1.2beta

People

(Reporter: mrmazda, Assigned: morse)

References

()

Details

Attachments

(1 file)

2002032316 OS/2

Steps to reproduce:
1-Start Mozilla with enabled pref "load all images"
2-Load into tabs some web pages with embedded images
3-Enable pref "do not load any images"
4-Open new tab
5-Load a local file/page with embedded images
6-Load web copy of the page just loaded from local
7-Return to any/many of the web page tabs
8-Return to last tab
9-Hit back button
10-Hit forward button
11- . . .

Actual behavior:
1-Images in local files/pages are loaded
2-Unexpired images in web pages loaded prior to pref change are not displayed
3-Images in web pages loaded after pref change are not displayed

Expected behavior:
1-Images in local files/pages are not loaded
2-Unexpired images in web pages loaded prior to pref change are displayed
3-Images in web pages loaded after pref change are not displayed
s/load all images/accept all images/
->Image Management
Assignee: attinasi → morse
Component: Layout → Image Management
QA Contact: petersen → tever
Not OS/2 specific

I think this is WAD though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OS/2 → All
Hardware: PC → All
Summary: [OS/2] "Do Not Load Any Images" Behavior Ignored for Local Pages → "Do Not Load Any Images" Behavior Ignored for Local Pages
I know this is a subtle distinction, but image management has to do with 
selective image blocking.  Total image blocking is not handle by the image 
management code but rather by imagelib itself.

Reassiging.
Really reassigning this time.
Assignee: morse → pavlov
Component: Image Management → ImageLib
QA Contact: tever → tpreston
Imagelib does *no* blocking.  The code in layout that uses imagelib does a
content policy check which checks with your stuff.  I don't know how this code
works.  This is either your bug or whoever owns content policies.
Assignee: pavlov → morse
Component: ImageLib → Image Management
QA Contact: tpreston → tever
Target Milestone: --- → mozilla1.2beta
For Win98 build ID 2002042403, I have confirmed that even with "Do Not Load Any
Images" selected, Mozilla will load any images for locally stored HTML documents
(local and remote images), regardless of whether they were visited, expired or
whatever (I think).  I have a super-simple example that demonstrates this
bug/feature, hopefully more simply than the original report.

1. Select "Do Not Load Images" option under Privacy & Security|Images prefs
2. Purge cache with the "Clear Memory Cache" and "Clear Disk Cache" buttons
under the Advanced|Cache prefs
3. Exit all Mozilla instances
4. Delete any files in my profile's cache folder (don't know if I have to)
5. Open Mozilla and load the following very simple document:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>Don't Load Images, Please</title>
</head>
<body>
<img src="http://www.google.com/images/logo.gif">
</body>
</html>

The image loads when viewing the above document, but the very same image does
not load when we visit Google, even though the same URL is given in an IMG tag's
SRC attribute.
Hope this helps.
By the way, doesn't this bug have some significant overlap with Bug 64068 ("Set
Image blocking (preferences) doesn't work for local drives!")?  In fact, isn't
this bug just a more general case of that bug?
Which is better to mark as the dupe (if either)?  The other one has been around
longer, but this one seems like a more generalized case (includes erroneous
loading of remote images when document is local) and so maybe is better to pay
attention to.
Maybe Morse has a comment?
I am using Build 2002050108, Win98
I have another observation.  Having activated "Do Not Load Any Images" if one
inserts a BASE tag in a local HTML document, any remote images referenced on
that page will not be displayed, although images stored locally are still
displayed.  It does not seem to matter what the BASE tag's HREF attribute is,
but the HREF attribute must be present in the BASE tag to cause this effect. 
This effect is also observable without "Do Not Load Any Images" being activated
when I have blocked images from the given server only.
Without the BASE tag, the effect described in the original report is still
observable (that is, "Do Not Load Any Images" Behavior is ignored for local
pages, even when the image referenced in the SRC attribute of an IMG tag is
remote).  (I think this was what was meant in the original report).
You can try copying the HTML below and pasting it into a file and saving that
locally.  Then activate "Do Not Load Any Images", or "block images from this
server" the first time you load the page.  Can someone explain why the <BASE
HREF=..> makes image blocking work (at least makes the images not display when
they shouldn't) and how it may or may not relate to this bug?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html lang="en">
<head>
<title>BASE Tag makes image blocking work</title>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<base hRef="http://www.mozilla.org/">
</head>
<body>
<img src="http://www.mozilla.org/images/mozilla-banner.gif" alt="The Mozilla
Project" width=600 height=58 border=1>
</body>
</html>
HTML doc shows remote images are blocked when we use <BASE HREF="..."> in a
local HTML document.
This is basically my last comment's HTML pasted into an easy-to-use file.  Save
it locally to observe this effect.
This can be used as a workaround if you want to be able to block remote images
referenced in local documents (still does not work to block _local_ images, no
matter what HREF attribute is used).  Why you would want to do this, I have no
idea (since you would have to have control over the HTML to add the BASE tag
anyway and could therefore remove the references to offending images anyway),
but it sure is interesting.
*** Bug 151586 has been marked as a duplicate of this bug. ***
Someone should consider duping this against Bug 51266.
Duping against bug 64068.  This one has more detail and, by that very nature, is 
more confusing.  Therefore I'd rather leave the simpler bug as the open one.  If 
there is any important detail here that is not mentioned in 64068, then please 
copy it over, but keep it simple.

*** This bug has been marked as a duplicate of 64068 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
QA Contact: tever → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: