Created attachment 606931 [details] Test case This is fallout from bug 674473 (based on when the error started occurring). Basically, if you have a message like so: root 1.txt message.eml 2.txt and you open message.eml, it shows 1.txt and 2.txt as attachments in the attachment pane. We should fix this.
Created attachment 606935 [details] [diff] [review] Fix this I tried for a while to write a test for this, but I couldn't figure out how to stream an attached message through XPCShell. Oh well.
(In reply to Jim Porter (:squib) from comment #1) > Created attachment 606935 [details] [diff] [review] > Fix this > > I tried for a while to write a test for this, but I couldn't figure out how > to stream an attached message through XPCShell. Oh well. I'll have a crack at figuring out how to do that, but a mozmill test should be straightforward.
When we load the inner .eml file, we call nsMessenger.LoadUrl with "mailbox:///C:/Users/<user>/AppData/Local/Temp/message-1.eml?number=0&part=1.3&filename=Inner%20message.eml&type=application/x-message-display&filename=Inner%20message.eml" I'm wondering if streaming some variation of that as a message would allow us to test the mime handling of the inner part. Or is that what you tried? I think StreamMessage will add the ?number=0, so you probably wouldn't need that.
Comment on attachment 606935 [details] [diff] [review] Fix this seems to work fine. I think some sort of unit test would really be helpful here, though, since this isn't the first time we've broken something with .eml file handling, and most developers don't do it often...
Created attachment 607427 [details] [diff] [review] Add Mozmill test I got sick of trying to make XPCShell handle this, so let's test this via Mozmill. I have a try build in progress here: http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=da7a5addded8
One thing of note: this will hide undisplayable multipart/alternative subparts again (e.g. ICS "attachments"), but that's ok, since they weren't actually openable. I have a separate patch to fix that for once and for all, which I'll upload just as soon as I find the bug number again...
(In reply to Jim Porter (:squib) from comment #7) > I have a separate patch to fix that for once and for all, which I'll upload just as soon > as I find the bug number again... That's bug 505024, but it turns out it's somewhat more complicated than it seemed. Given that this is libmime, I suppose I should have expected that.
Oh, and here's another try build, as the first one failed: http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=a5d7524b24d1 (I thought I'd run a second try build that passed, but I can't find it, so I'll just be safe...)
Comment on attachment 607427 [details] [diff] [review] Add Mozmill test [Approval Request Comment] Regression caused by (bug #): bug 674473 User impact if declined: Opening attached .eml files will show bogus attachments in the list (granted, this is probably relatively rare). Testing completed (on c-c, etc.): Successful try build here: http://build.mozillamessaging.com/tinderboxpushlog/?tree=ThunderbirdTry&rev=c3f31c6e6be8 Risk to taking this patch (and alternatives if risky): Low; the code change is pretty simple, despite it being in libmime.
Checked into branches: http://hg.mozilla.org/releases/comm-aurora/rev/f372e5ce68d6 http://hg.mozilla.org/releases/comm-beta/rev/a4c78c9d4606
I've had to back this out of branches due to test failures. I tried porting bug 736881 and that didn't fix them locally for me either. Test Failure: SyntheticPartMultiMixed is not defined NEXT ERROR TEST-UNEXPECTED-FAIL | /builds/slave/comm-aurora-macosx-opt-unittest-mozmill/build/mozmill/attachment/test-attachment.js | test-attachment.js::setupModule http://hg.mozilla.org/releases/comm-aurora/rev/dd23e7852b24 http://hg.mozilla.org/releases/comm-beta/rev/7fa1ab94c06b
Given the orange, and we're at the final beta, we're going to leave fixing this for 12. We'd still like to work out about fixing it for 13, and getting whatever we need landed there.
squib, do you have time to work on the backport in the next week or so?
Unfortunately we've not been able to backport this, and we've now not got time before TB 13. The issue is significant because you'll still be able to get to all attachments.