Closed Bug 1251408 Opened 9 years ago Closed 9 years ago

Replying or forwarding a message with external image doesn't not show the image in the composition

Categories

(Thunderbird :: Message Compose Window, defect)

38 Branch
defect
Not set
normal

Tracking

(thunderbird44 wontfix, thunderbird45+ fixed, thunderbird46 fixed, thunderbird47 fixed)

RESOLVED FIXED
Thunderbird 47.0
Tracking Status
thunderbird44 --- wontfix
thunderbird45 + fixed
thunderbird46 --- fixed
thunderbird47 --- fixed

People

(Reporter: jorgk-bmo, Assigned: jorgk-bmo)

References

Details

Attachments

(2 files, 2 obsolete files)

Replying or forwarding a message with external image (for example sent with img moz-do-not-send="true") doesn't not show the image in the composition although the image is shown when received (assuming that images from that site are allowed). Or take any HTML e-mail with external images and reply. Is this some origin/security problem? This does not happen when you check: Tools > Options, Privacy tab, Allow remote content in messages. Surely if the images are visible when viewing the message they should be visible when replying/forwarding.
Magnus, can you take a look at this. You worked on this area. It's really quite annoying that you don't see the images in your reply.
Flags: needinfo?(mkmelin+mozilla)
Sadly, the last time this has worked was in TB 24. It stopped working with TB 31, not working in TB 38, TB 46 or latest trunk. And no one has noticed or complained.
This is bad enough to allow tracking for TB 45.
Attached patch Proposed solution (v1). (obsolete) — Splinter Review
This does the trick. I've we're composing, we also test the whitelist of sites.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Flags: needinfo?(mkmelin+mozilla)
Attachment #8723858 - Flags: review?(mkmelin+mozilla)
I'm just looking at the blame of nsMsgContentPolicy.cpp. A few bugs in the area: Bug 374578, bug 605140 and most prominently bug 953426. Looks like in bug 953426 (which landed on TB 31) you forgot to apply the "per host" privileges to the message being composed.
Comment on attachment 8723858 [details] [diff] [review] Proposed solution (v1). Review of attachment 8723858 [details] [diff] [review]: ----------------------------------------------------------------- I think you should add the permission manager tests to ComposeShouldLoad instead of falling through, to keep the logic more simple. nsMsgContentPolicy.cpp changes are really required to include a test though (see mail/test/mozmill/content-policy/)
Attachment #8723858 - Flags: review?(mkmelin+mozilla)
Attachment #8723773 - Attachment mime type: message/rfc822 → text/plain
Attached patch Proposed solution (v2). (obsolete) — Splinter Review
(In reply to Magnus Melin from comment #6) > I think you should add the permission manager tests to ComposeShouldLoad > instead of falling through, to keep the logic more simple. Agreed. The patch looks big due to reshuffling of if-blocks, but it's really only this: + // Test whitelist. + uint32_t permission; + mPermissionManager->TestPermission(aContentLocation, "image", &permission); + if (permission == nsIPermissionManager::ALLOW_ACTION) + *aDecision = nsIContentPolicy::ACCEPT; > nsMsgContentPolicy.cpp changes are really required to include a test though > (see mail/test/mozmill/content-policy/) How about doing this next week? Right now I'm far away from home (2000 km). Would be nice to have this while we're still on TB 47 so uplift is simpler.
Attachment #8723858 - Attachment is obsolete: true
Attachment #8725355 - Flags: review?(mkmelin+mozilla)
Generally it's not a good idea to land tests independently from the code fix, since they should verify the code works. In this case the test would have to land later anyway so there's no win in a multi-landing.
Enjoy your trip though, this has apparently been broken for years so there's no immediate hurry :)
Well, the immediate hurry is that if it doesn't land now, it will be harder to get into 45.x.
Bad luck, test have just gone bust, so that run doesn't tell us a thing.
A quick check already found three duplicates. The hurry *is* that's it's been broken for year.
OK, the solution is unchanged from the previous version, and I added a test.
Attachment #8725355 - Attachment is obsolete: true
Attachment #8725355 - Flags: review?(mkmelin+mozilla)
Attachment #8726163 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8726163 [details] [diff] [review] Proposed solution (v2) and modified test. Review of attachment 8726163 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, I'll land it in a bit. r=mkmelin
Attachment #8726163 - Flags: review?(mkmelin+mozilla) → review+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 47.0
Comment on attachment 8726163 [details] [diff] [review] Proposed solution (v2) and modified test. [Approval Request Comment] Regression caused by (bug #): Bug 953426. User impact if declined: Very annoying behaviour that images don't show on reply/forward. Testing completed (on c-c, etc.): Manual + adapted test. Risk to taking this patch (and alternatives if risky): Minimal clear code change, little risk.
Attachment #8726163 - Flags: approval-comm-beta?
Attachment #8726163 - Flags: approval-comm-aurora+
Attachment #8726163 - Flags: approval-comm-beta? → approval-comm-beta+
Attachment #8726163 - Flags: approval-comm-beta+ → approval-comm-esr45+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: