Open Bug 1575330 Opened 5 years ago Updated 2 years ago

Consider blocking images when they are referencing other messages without displaying an unblock notification

Categories

(MailNews Core :: Composition, task)

Tracking

(Not tracked)

People

(Reporter: jorgk-bmo, Unassigned)

References

Details

Attachments

(1 file)

+++ This bug was initially created as a clone of Bug #1572864 +++

In bug 1572864 we found that processing in nsMsgCompose::IsEmbeddedObjectSafe() is inconsistent. For IMAP, the URL of the embedded image is checked to the level of the message number, for mailbox, we only check the folder.

There is code here
https://searchfox.org/comm-central/search?q=reference.*random.*message&case=false&regexp=true&path=mail%2F
that handles access to "random" messages. That code could be changed or removed, if the patch here went ahead.

Whiteboard: [has protocol log]

So here's the idea from attachment 9086714 [details] [diff] [review] from bug 1572864 rebased.

Attachment #9086784 - Flags: feedback?(mkmelin+mozilla)
Attachment #9086784 - Flags: feedback?(gds)
Attachment #9086784 - Flags: feedback?(acelists)

Of course the code around https://searchfox.org/comm-central/search?q=reference.*random.*message&case=false&regexp=true&path=mail%2F would also need to change. Magnus is the best judge of this since he wrote it.

Comment on attachment 9086784 [details] [diff] [review] 1575330-IsEmbeddedObjectSafe.patch Looks correct to me.
Attachment #9086784 - Flags: feedback?(gds) → feedback+

Thanks, Gene.

As the removed comment says, there are at least four cases to look at: mailbox (local folder), IMAP, news and saved message. And at least for the first two, we need to try references to other messages, like you did in bug 1572864 comment #31. Then we need to see what to do with the code in MsgComposeCommands.js whether might not be relevant any more. And then, we need to experiment with "Quote message".

Tightening the code in IsEmbeddedObjectSafe() has the consequence of adding "moz-do-not-send" to the image has as a consequence that it's skipped here:
https://searchfox.org/comm-central/rev/d55fb7f2405fd4e07cb267851340626a63a8c270/mail/components/compose/content/MsgComposeCommands.js#6696

So then the message goes out with a "funny" mailbox reference. On the other hand with the patch, there will no longer be "funny" notifications to unblock those "funny" images.

There are a lot of details to consider, so I landed a simple solution which doesn't change behaviour in bug 1572864.

I think, Magnus should do some brainstorming why he added the code to handle access to random "messages".

AFAIR, handling "random" messages with the notification was just in case there are some unknown valid scenarios.

Type: enhancement → task
Comment on attachment 9086784 [details] [diff] [review] 1575330-IsEmbeddedObjectSafe.patch Review of attachment 9086784 [details] [diff] [review]: ----------------------------------------------------------------- I suppose this is ok, though I really think it's playing with fire trying to do url extraction and manipulation like this, in hard to read c++.
Attachment #9086784 - Flags: feedback?(mkmelin+mozilla) → feedback+

Thanks, as stated in comment #4, this needs more work in MsgComposeCommands.js.

Comment on attachment 9086784 [details] [diff] [review] 1575330-IsEmbeddedObjectSafe.patch Review of attachment 9086784 [details] [diff] [review]: ----------------------------------------------------------------- I like that we tighten the check, but I can't comment on whether it has consequences in false positives. We will probably see in tests or real life use.
Attachment #9086784 - Flags: feedback?(acelists) → feedback+
Assignee: nobody → jorgk
Assignee: jorgk-bmo → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: