Filter "real" attachments by being referenced #9472
Conversation
pabzm
force-pushed
the
filter-attachments-by-reference
branch
from
d7adcf0
to
72ff9f3
Compare
|
Looks to me that it fixes #9443 only partially. With I think for |
That's because the message was considered empty and thus no body was rendered. An issue that is not exactly in scope of this PR, but because it is related to handling mime-parts I fixed it nonetheless in here. Now the image is shown inline as expected. I'd be happy to clean up the commit history before merging if you'd agree. |
|
Wait a moment, I'll have to rebase to "master" anyway, and then I can clean the history a little, too. |
pabzm
force-pushed
the
filter-attachments-by-reference
branch
from
49b3de4
to
6723329
Compare
This changes the way in which attachments are determined to be shown as
such ("standalone"), or not ("inline").
In theory this should be determined by their Content-Disposition, but in
reality this often doesn't work.
Now we check if the Content-ID or Content-Location of the attachment is
actually being used in other parts of the message. If not, the
attachment is considered to be "standalone".
Previously only `parts` and `body` were checked, so mime-parts that were classified into `attachments` and `inline_parts` didn't count – thus messages that contained only those parts were shown blank.
pabzm
force-pushed
the
filter-attachments-by-reference
branch
from
6723329
to
355bcca
Compare
|
@alecpl I rebased onto the latest master. Could you merge this or let me know what's blocking it, please? |
|
@alecpl Just a note: I would prefer if you wouldn't use squash-commits when merging, because it makes rebasing much harder (git can't automatically identify the commits that were used before). If you don't like a list of commits please just ask to clean it up. |
This changes the way in which attachments are determined to be shown as downloadable ("standalone"), or not ("inline").
In theory this should be determined by their
Content-Disposition, but in reality this often doesn't work.Previously, on top of the default standard handling, edge cases have been fixed by checking for their concrete details.
Now the code checks if the
Content-IDorContent-Locationof the attachment is actually being used in other parts of the message. If not, the attachment is considered to be "standalone". This might make some images be shown as downloadable, which have a "inline"-disposition – but it'll happen only in cases where the message is broken, or they wouldn't have been shown at all previously. So I consider this a progression while staying a comprehensible and review-able changeset.This fixes #9443.
I didn't find an email that it breaks. I also don't see how it could.
It helps #9465, too.
And it (unintendedly) also helps #9326, because now the information, which image is actually referenced in an HTML-part, ist available already after message parsing.