Remote images are loaded even if I check "Do not load remote images" in preferences



MailNews Core
15 years ago
9 years ago


(Reporter: Frederic Bezies, Assigned: (not reading, please use instead))


({privacy, regression})

privacy, regression

Firefox Tracking Flags

(Not tracked)



(1 attachment)



15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030328
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030328

All in the summary. Some junk mail are loading remote images, even if I said no,
by checking "do not load remote..." in prefs panel.

I search in Bugzilla and I don't find a bug like this one.

Sorry if it is a duplicate.

Reproducible: Always

Steps to Reproduce:
1.Verify that option "Do not load remote images" is checked in preferences
2.Load a junk mail with a remote image in it
Actual Results:  
Image is loaded

Expected Results:  
Image not loaded.

Could it be related to bugfix for bug 198301, checked in 9 days ago ?

Comment 1

15 years ago
Confirming bug on OS/2 build 2003032712
OS -> All
OS: Windows XP → All

Comment 2

15 years ago
Isn't it a security issue?
Security component seems more suitable for the bug.

Comment 3

15 years ago
I have another details to add.

This bug is weird, because it only appears when you uncheck option, confirm your
choice, and check it again.

Hope it helps ?

Comment 4

15 years ago
And last detail (sorry for /spamming/), this bug disappears (see comment #3),
when you *completely* exit mozilla. So is quicklaunch related to this bug ?

It is a very very weird bug !

Comment 5

15 years ago
I cannot confirm comments #3 and #4.
Playing with the option and restarting Mozilla have no effect here.

Comment 6

15 years ago
Switching component to Security since the bug allows the spammers to have
implicit confirmation that their mail reached destination and got the
recipient's attention.

P.S. On my system almost every mail with remote images is a spam.
Component: Mail Window Front End → Security: General

Comment 7

15 years ago
I do agree with comment #6.

Nominating it as a "?" blocker for 1.4b
Flags: blocking1.4b?

Comment 8

15 years ago
This seems to have been caused by:

1.19	Mar 21 17:24	 	Checking in permissions rewrite phase 1
(troop deployment in the permission
gulf). Bug 191380, patch by (Michiel van Leeuwen),, sr=darin.
ccing the people who may actually know something about this code.. (hint: the
person checking in the code may not know much about it; the patch author and
reviewers are the ones to cc...)

First, are Frederic and Max seeing the same bug?  Frederic's sounds like someone
forgot to register a pref observer, so that pref changes need a restart to take
effect.  Max's sounds like something a little more fundamental is broken...
Keywords: privacy, regression
Created attachment 119656 [details] [diff] [review]
It is a boolpref

This is when reading changed preferences. No further comments...
I should fix the problem that you need to restart mozilla. Not sure about the
other one.

Comment 11

15 years ago
Comment on attachment 119656 [details] [diff] [review]
It is a boolpref

indeed. ;)
Attachment #119656 - Flags: review+
Attachment #119656 - Flags: superreview+

Comment 12

15 years ago
Fix checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 13

15 years ago
clearing 1.4 blocker request, since the fix has landed.
Flags: blocking1.4b?

Comment 15

15 years ago
I'm still seeing this behavior in Mozilla 1.4 [Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.4) Gecko/20030624]  The image link was:

<IMG =

in the message source.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.