Closed Bug 406825 Opened 12 years ago Closed 2 years ago

Blocked images appear when replying or forwarding

Categories

(MailNews Core :: Composition, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1409458

People

(Reporter: deathburger+bz, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082801 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a8pre) Gecko/2007082801 SeaMonkey/2.0a1pre

If I receive a message and an image in it gets blocked it doesn't get displayed, as expected. However if I forward or reply - without clicking the button to say it's okay in the original message - the image will load. That defeats the purpose of blocking images as forwarding or replying could confirm to a spammer that the message was received by someone.

Reproducible: Always

Steps to Reproduce:
1. Receive a message with a blocked image
2. Reply to it or forward it

Actual Results:  
Image is loaded in the compose window

Expected Results:  
Image should be blocked until it gets okayed by the user

This isn't specific to the version of SeaMonkey I'm using. 1.x did it as well.

I don't use Windows or Mac so I can't say if it's a problem there but it probably is.
Mozilla/5.0 (X11; U; Linux i686; rv:1.9pre) Gecko/2008041401 SeaMonkey/2.0a1pre

Confirming, Composer should respect image blocking rules.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Core → MailNews Core
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Composition
Product: Mozilla Application Suite → Core
QA Contact: composition
Version: unspecified → Trunk
Duplicate of this bug: 518664
OS: Linux → All
Hardware: x86 → All
This was previously fixed in bug 263345, and didn't happen in 45.8.0, but I'm seeing it again in Thunderbird 52.4.0/56.0b4. Replying to a message with a blocked tracking image attempts to load that image. After switching back to 45.8.0 it doesn't happen.
Forward duplicate, let's look at it in bug 1409458.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1409458
This bug was reported for SM which has this interesting bit of extra code:
https://dxr.mozilla.org/comm-central/rev/952762964f408e33d060dd1110cac0626ae5fa51/mailnews/base/src/nsMsgContentPolicy.cpp#171

FRG, Ian, any idea what this is about? I've duped this to bug 1409458 (which I can't reproduce), so can you try in SM.
Flags: needinfo?(iann_bugzilla)
Flags: needinfo?(frgrahl)
The bug rings a bell. Encountered it when doing fixes in bug 1322172 but forgot to look into it further. I think I can reproduce it just just doing a reply. I will let the needinfo stay and will check the code (hopefully not in the next life... ).
(In reply to Jorg K (GMT+1) [currently bustage-fix only, no NI? or r?] from comment #5)
> This bug was reported for SM which has this interesting bit of extra code:
> https://dxr.mozilla.org/comm-central/rev/
> 952762964f408e33d060dd1110cac0626ae5fa51/mailnews/base/src/
> nsMsgContentPolicy.cpp#171
> 
> FRG, Ian, any idea what this is about? I've duped this to bug 1409458 (which
> I can't reproduce), so can you try in SM.

This code should just make sure that the window is a mail window and not a browser or other non-mail window.
Flags: needinfo?(iann_bugzilla)
For what it is worth. Finally found some time to test this in SeaMonkey and the bug applies. Replying to an email with blocked images unblock them in the reply. I will open a new bug for SeaMonkey and see if a port of bug 1409458 solves it.
Flags: needinfo?(frgrahl)
You need to log in before you can comment on or make changes to this bug.