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®exp=true&path=mail%2F
that handles access to "random" messages. That code could be changed or removed, if the patch here went ahead.
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Comment 1•5 years ago
|
||
So here's the idea from attachment 9086714 [details] [diff] [review] from bug 1572864 rebased.
Reporter | ||
Comment 2•5 years ago
|
||
Of course the code around https://searchfox.org/comm-central/search?q=reference.*random.*message&case=false®exp=true&path=mail%2F would also need to change. Magnus is the best judge of this since he wrote it.
Comment 3•5 years ago
|
||
Reporter | ||
Comment 4•5 years ago
|
||
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".
Comment 5•5 years ago
|
||
AFAIR, handling "random" messages with the notification was just in case there are some unknown valid scenarios.
Comment 6•5 years ago
|
||
Reporter | ||
Comment 7•5 years ago
|
||
Thanks, as stated in comment #4, this needs more work in MsgComposeCommands.js.
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Reporter | ||
Updated•5 years ago
|
Updated•2 years ago
|
Description
•