Closed Bug 1216914 Opened 5 years ago Closed 4 years ago

Drafts.msf deleted when viewing a message that contains a reference to the drafts folder like img src="mailbox:///.../Drafts?number=... in an unrelated folder

Categories

(MailNews Core :: Database, defect)

defect
Not set
critical

Tracking

(thunderbird43 wontfix, thunderbird44 wontfix, thunderbird46 wontfix, thunderbird47 fixed, thunderbird48 fixed, thunderbird49 fixed, thunderbird_esr4548+ fixed)

RESOLVED FIXED
Thunderbird 49.0
Tracking Status
thunderbird43 --- wontfix
thunderbird44 --- wontfix
thunderbird46 --- wontfix
thunderbird47 --- fixed
thunderbird48 --- fixed
thunderbird49 --- fixed
thunderbird_esr45 48+ fixed

People

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

References

Details

(Keywords: dataloss, regression, regressionwindow-wanted, Whiteboard: [regression:TB4?])

Attachments

(5 files, 2 obsolete files)

I've recently switched to Earlybird 43 and I've experienced many cases where my Drafts folder got corrupted.

Every once in a while superseded drafts (X-Mozilla-Status: 0008) which got saved (automatically or manually) while editing messages show up as new messages in the drafts folder. In one case I had about 50 "new" messages showing, which were multiple versions of about 10 messages sent during the day.

I'll provide more details when it happens again. Sadly I don't have a reproducible case.

(I really dislike reporting such a vague problem, but I'm hoping others might have the same problem and can help make it reproducible.)
Version: Trunk → 43
> I've recently switched to Earlybird 43 

from beta?  or from nightly?

It definitly happens in 44, or is that an assumption?
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #1)
> from beta?
From 41 beta.

> It definitely happens in 44, or is that an assumption?
Assumption, sigh. I'm just afraid this is going to hit us if we ship this.
Keywords: regression
Since reporting the bug, I've moved to a later version of Earlybird 43 (18 Oct. 2015) and now to Earlybird 44 (8 Nov. 2015) and haven't seen the problem again.
This is the silliest bug I've ever reported. Since the day I've reported it, I have not seen it any more. For the last ten days I've been using a Daily of 13-Nov-2015. Ah well, I'll close this for now.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WORKSFORME
Just happened again, this time in Earlybird 45. I clicked the drafts folder, heard some rattling on the hard drive as if something was going on, and then ended up with five superseded drafts with this status:
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
Not even the 0x10 bit (HasRe) was set, although these zombie messages are replies.

The folder contains more superseded messages which have status:
X-Mozilla-Status: 0018 (HasRe + Expunged)
X-Mozilla-Status2: 00000000

Kent, what would trigger a (faulty) rebuild of the mailbox?

This time I made a copy of the folder right after it happened. Is there anything I should look for?
Status: RESOLVED → REOPENED
Flags: needinfo?(rkent)
Resolution: WORKSFORME → ---
Some more details:

The mbox file is 10 MB big, it has 347 messages, 341 of which have the 0x8 bit set, so they are expunged. 6 have X-Mozilla-Status: 0000, and five of them are superseded drafts which have reappeared, one is a genuine draft which I saved before clicking onto the Drafts folder in the user interface.

The MSF file is very small, 5 KB, and without knowing anything about Mork databases, it looks like only the last "visible" messages are referenced there.

So if I were to fantasise about what happened, I'd say this: 341 superseded drafts were marked expunged in the mailbox, five weren't, they might have been marked only in the MSF file. At some stage the system decided to auto-repair the folder and then the five expunged messages reappeared.

Auto-compact is switched off.
There is an integrity check when databases are open that checks a variety of things. Some of them are in nsMsgDatabase::CheckForErrors but not all. Like, I know that in local folders there is also a check of time when the file was updated, but I don't see it there.

It is a very confusing and frustrating area. But in this bug, your issue is really that the rebuild fails to work correctly, not that it happens at all. If this will repeat itself, what you might do is make copies of the draft folder and db periodically, then when it happens you will have a copy of the raw messages and db, and you should be able to debug at least why the rebuild fails.
Flags: needinfo?(rkent)
This will be very hard to catch since it happens about every two months. I'd have to take a copy of the drafts folder about every 30 seconds if it's changed and keep - say - five copies not to miss the copy that causes the problem.

> your issue is really that the rebuild fails to work correctly,
> not that it happens at all.
But why would a rebuild be triggered in the first place? That shouldn't happen, or should it?

Also, is it correct that there are superseded draft messages in the raw data which are not marked as "expunged"? Is this not where the corruption starts? Or is the status "cached" in the db file and flushed out later? As far as I can see, the rebuilt db file matches the raw data, that is, messages with status 0 are visible and unread after the rebuild.
Flags: needinfo?(rkent)
(In reply to Jorg K (GMT+1) from comment #8)

> 
> Also, is it correct that there are superseded draft messages in the raw data
> which are not marked as "expunged"? Is this not where the corruption starts?
> Or is the status "cached" in the db file and flushed out later? As far as I
> can see, the rebuilt db file matches the raw data, that is, messages with
> status 0 are visible and unread after the rebuild.

I really can't answer these questions without pouring over the code. All I can say is that problems like you are having are usually only fixable when they are reproducible, so the path to fixing is getting something that can be reproduced. Every two weeks is in that sour spot where it it frequent enough to be annoying, but not frequent enough to be easily caught. A tough problem.
Flags: needinfo?(rkent)
Actually, not every two weeks, two *months* passed between the last two occurrences. I've written a script that takes a snapshot of my drafts folder every 30 seconds if the folder is different to the previous snapshot. Sooner or later I will have a reproducible case.
It just happened again, after one month (last occurrence: Dec. 19th, 2015). And since it was early in the morning, I hadn't started the script to take the snapshots yet. Grrrr.
OK it happened again, just one day later. I was writing a long e-mail to a friend, saving and auto-saving while I was writing, also looking for photos to attach and attaching them. In short, it took a while to compose the e-mail.

This time I had my snapshot tool running. The way it works: It keeps copies of Drafts and Drafts.msf in a separate directory. Every 30 seconds it checks for differences on the Drafts file, if found it moves the local copy appending date and time to the filename. Then it copies Drafts and Drafts.msf from the source.

This is what my script reported, I've added comments after the <--:

Thu Jan 21 10:46:32 W. Europe Standard Time 2016 <-- no change detected
Thu Jan 21 10:47:02 W. Europe Standard Time 2016 <-- change detected
Moving file at 2016-01-21-10-47-02
File not found - Drafts.msf <-- copying the file from the profile directory failed!!!
Thu Jan 21 10:47:32 W. Europe Standard Time 2016 <-- another change detected
Moving file at 2016-01-21-10-47-32
The system cannot find the file specified. <-- error message from the move command.
                                           <-- since copying the Drafts.msf failed, there is no copy
                                           <-- than can be moved.
File not found - Drafts.msf <-- still no Draft.msf to be found.
Thu Jan 21 10:48:02 W. Europe Standard Time 2016
Thu Jan 21 10:48:32 W. Europe Standard Time 2016

So for some reason the Drafts.msf file disappears from the mail directory. Next time I click on the folder, the system busily recreates the MSF file from the raw messages.

All the superseded drafts have this status
X-Mozilla-Status: 0000
X-Mozilla-Status2: 00000000
and of course reappear.

I'd like to add: My Drafts folder is a local folder.

So have you heard of any occurrences where MSF files disappear?
Flags: needinfo?(rkent)
So the problem can be "manually" created:
(Preferably clear out the Drafts folder and compact it to start with a clean slate.)
Write a new message and save it to Drafts. (*)
Exit TB and delete the Drafts.msf
Start TB again and compose a new message. Save a few times.
Notice that the Drafts folder does NOT show *(1)* for one saved draft.
Click on the Drafts folder. All superseded drafts spring back to life.

The behaviour is different if step (*) is left out and the drafts folder is completely empty. Then composing a message and saving drafts will work OK with the *(1)* showing.

So there seem to be two problems here:
1) Drafts.msf gets lost. It's downhill from there.
2) If Drafts.msf is not present, message deletions seem to be buffered but this gets lost
   when recreating the MSF file.
I'm not aware of cases were the .msf folder gets deleted.

Drafts is one of those special folders where the folder URL may not match the file name, which IMO was a bad design decision years ago. Is your Drafts localized? I could imagine if it is cases where the system gets confused between the real name, the folder URL special name (Drafts), and the localized name. Lots of possible ways to go wrong.
Flags: needinfo?(rkent)
No. Not localized. Straight en-US Earlybird.

I'm wondering how the .msf folder is updated. I can see that in Windows the file size is at times displayed as zero. So it looks like the file got erased programmatically to be rewritten. And if for some reason the new creation fails, we would get the problem.

The drafts folder is a "high traffic" folder so it might trigger the problem more frequently than other folders. Also, the drafts folder may contain many deleted messages, so it's more obvious when they reappear. I really don't know. All I can say that there is a gremlin in the box that's hard to catch since it only raises its ugly head very rarely.
The worst kind of bug is frequent enough to cause problems, but not frequent enough to be actually caught.

One way to catch this would be to run a local build yourself, and modify the file delete routine to do a crash (an assertin a release build, however this is done in a release build, I forget) when some code tries to delete the Drafts folder. That would of course require you to run this all of the time until it happens again. Then when the delete occurs and the crash occurs, you could attach a debugger and see what the code path is that got you there.
great comment 16

> So have you heard of any occurrences where MSF files disappear?

Drive by comment FWIW. For a considerable period of time, I've been experiencing folder rebuilds - I know this because my columns get reset. I haven't figured out how or why. And I can't speak to whether there has been loss of header data such as X-Mozilla-Status

also see wada's comments starting at bug 812786 comment 19. It's not all that much about *causes*, which is what you want, but perhaps it will trigger some thoughts
Severity: normal → major
Summary: Drafts folder corrupted, superseded messages showing up as new. → Drafts folder corrupted. Superseded messages showing up as new, not replies
Whiteboard: [regression:TB4?]
With all due respect, trying to find a regression window for a bug that shows up every month or two months will take longer then we all have to live, even if you combine all the years.

I put "regression" since in my six years of Thunderbird usage I've only recently come to experience the problem. So most likely it's a new problem caused by something.

Clearly the bug here is caused by a folder rebuild. The MSF file is rebuilt from the raw message file and that has messages with status 0000 in them. The database that marks those messages as deleted got lost somehow.

I think we could at least tackle part 2) of the problem mentioned in comment 13). If the system detects a problem with the MSF file, for example missing, it should rebuild straight away and not buffer message deletions internally until the user clicks onto the folder and forces a rebuild.

I haven't looked at the code at all so far (too busy with other issued) but I hope to look at it next week. Also, I hope to see another case soon. I believe the bug will only show if there are some saved drafts present to start with.
(In reply to Jorg K (GMT+1) from comment #18)
> I believe the bug will only show if there are some saved drafts present to
> start with.
In fact, that might be the key to it.

Before I used the Drafts folder for miscellaneous "notes". So I always had plenty of drafts/notes. When I first experienced the bug, I moved those "notes" to a different folder and worked with an empty drafts folder. This way the bug happens rarely. Recently I "accidentally" ended up with some drafts left over from some testing, and bingo, the problem showed up again and frequently like when I first raised the bug.
OK, it just happened again. I was writing a long e-mail which got (auto-)saved many times. I've just noticed that the Drafts folder doesn't show the *(1)* indicating one new draft, the one I'm currently writing.

Sadly I hadn't started my capture script. So I went to start it before clicking onto the Drafts folder to see the problem. And lo and behold, as in the comment #13, Drafts.msf was lost and it's downhill from there.
Happened again yesterday, superseded drafts from two days sprang back to life.

Kent, when you have a spare five minutes, can you please do this experiment for me.

Go to your inbox.
Close Thunderbird.
Delete your Drafts.msf folder.
Monitor the folder that contained Drafts.msf in Windows Explorer.
Start Thunderbird again. You're in the inbox. DO NOT click on the drafts folder.
Observe that a zero-byte Drafts.msf got created.
Now write a new message. Press <ctrl>S once to save it.
Keep looking for the Drafts.msf, it is deleted when you first save the new draft.
Press <ctrl>S a few times to create superseded drafts.
Drafts.msf hasn't come back.
Now click on the drafts folder and you see all the superseded drafts.

Questions:
Why is a zero-byte Drafts.msf created? That's invalid, right? How come it's deleted again?
Why does the system not react and keep going when an invalid/no MSF is present.
Why doesn't it rebuild it at the earliest convenience?
How is it possible that superseded messages get piled up that are not marked superseded in the message file although the system ought to know that there is no database to store the deletion?

You've been looking at database issues very recently. Somehow you mentioned that the system is designed to keep going even with an invalid database. But how far will it keep going?

What I'm seeing here makes no sense at all:
1) It should not create a zero-byte MSF.
2) It should not delete the zero-byte MSF.
3) It should rebuild the MSF immediately when it finds it missing.
4) It should note deletions in the message file as they occur.

I don't understand yet why the drafts folder gets deleted in the first place, that might be an AV issue. But the system reacts real badly and that should be fixed.
Flags: needinfo?(rkent)
I don't need to try that since the behavior seems normal. Let me reply:

1) It should not create a zero-byte MSF.

Drafts is a special folder that is created on startup if missing, hence the 0 byte .msf

2) It should not delete the zero-byte MSF.

This is probably done as a step in rebuilding the folder.

3) It should rebuild the MSF immediately when it finds it missing.

Ideally yes, but rebuilding is an async process while simply opening is not. So not every use is setup to suddenly go into async mode and rebuild.

4) It should note deletions in the message file as they occur.

That's asking a lot if the msg database is inactive. I'm not sure there is any way to even figure out how to delete a draft with no database.
Flags: needinfo?(rkent)
OK, more on this sorry drama. After weeks without problem my script just alerted me to the fact that Drafts.msf had disappeared.

Here the captured files before the failure:
16/04/2016  10:48        39,719,411 Drafts-2016-04-16-10-48-26
16/04/2016  10:48             7,949 Drafts-2016-04-16-10-48-26.msf
16/04/2016  10:48        39,719,411 Drafts-2016-04-16-10-54-11     (*)
16/04/2016  10:54             7,971 Drafts-2016-04-16-10-54-11.msf (*)
16/04/2016  15:07        39,756,411 Drafts-2016-04-16-19-18-33
16/04/2016  18:32                 0 Drafts-2016-04-16-19-18-33.msf
<=== Alert here.
16/04/2016  21:12        39,762,473 Drafts-2016-04-16-21-44-21
16/04/2016  21:31                 0 Drafts-2016-04-16-21-44-21.msf

I went back to the last valid pair marked (*) and it seemed to be valid, no superseded drafts sprang back to life.

So it's still a mystery why the file gets lost (and then gets recreated with 0 bytes upon next start of TB).
Today I caught it.

My script copies Drafts and Drafts.msf every 30 seconds it if notices a change:

The last two copies were:
30/04/2016  07:59           205,113 Drafts-2016-04-30-07-59-15
30/04/2016  07:59             9,130 Drafts-2016-04-30-07-59-15.msf
30/04/2016  07:59           205,113 Drafts-2016-04-30-08-05-00
30/04/2016  08:04             5,186 Drafts-2016-04-30-08-05-00.msf

So at around 8:00 I had written the last e-mail for which a draft was saved.

It is now just after 12:35. My script alerted me that the Drafts.msf file has disappeared.

I had TB open and was busily shuffling messages from Inbox and Sent to the folders where I store them by correspondent.

So I was *absolutely NOT* accessing the drafts folder. I have no idea how Drafts.msf got deleted, but when I visit the mail storage folder, it's not there. The Drafts file is there and it is of course identical to the one copied at 7:59.

I restored Drafts.msf and the Drafts folder opened just fine.

I restored it again and I will continue to use TB without touching any draft and see whether it gets deleted again.
Kent, I have molested you with this bug many times, so here we go once more.

As you can read in comment #24 just above, on my system the Drafts.msf file spontaneously disappears.

I wasn't going anywhere near it, I wasn't writing any e-mail, I wasn't opening the drafts folder. It disappeared about 4.5 hours after it was last written.

Question: Do you have any idea why this could happen? Blaming it on my AV program seems too simple.

We know from comment #21 that all goes downhill once the MSF file has disappeared.
Flags: needinfo?(rkent)
No, I don't know why the drafts .msf file gets deleted, but the only known reason is when a reindex is called for.

If I was trying to catch this, what I would do is to build a release build locally, and try running it with a debugger enabled and a break point on the reindex trigger. Or you could patch the mozilla files delete method, scanning for the name of the file you are looking for, and break/Assert on that. Or you could check the available logging for the database access, make sure this is enough info to track why a reindex gets trigger, add & enable this logging.

All of this is of course a lot of work.
Flags: needinfo?(rkent)
My Drafts.msf went missing again (very annoyingly bringing many superseded drafts when I clicked onto the folder) so I am determined to get to the bottom of this.

Thanks for the advice. I have hooked into the Remove() function in xpcom/io/nsLocalFileWin.cpp. Like this, I've already discovered the unrelated bug 1269878.

I will run a debug version of a locally compiled Daily in production. That's not so bad since I'm already using TB 49 Daily anyway to keep on top of regressions.

Now, can you please tell me what exactly I need to code to get a stack-dump when it happens again. I don't intend to run TB always with the debugger attached. This only happens once a month, so it would be good to catch it the first time around.

Looks like Break() will do, right? I'll attach a patch in a few minutes.
Flags: needinfo?(rkent)
OK, it's called DebugBreak().
Flags: needinfo?(rkent)
Attachment #8748561 - Flags: feedback?(rkent)
Comment on attachment 8748561 [details] [diff] [review]
Patch to DebugBreak() when Drafts.msf is removed.

Yes that is probably good, but it is not something I have done much.
Attachment #8748561 - Flags: feedback?(rkent) → feedback+
I've been running with a debug version of TB for more than two weeks now.

A few days ago I caught a removal of a Drafts.msf which had zero bytes from nsMsgDatabase::CheckForErrors(). Obviously that came too late since the good (none empty) Drafts.msf had been removed before.

Today the following happened:
I was not writing message, nor going anywhere near the Drafts folder. I wanted to view a new message in the Inbox when suddenly Drafts.msf was removed.

Stack:
xul.dll!nsLocalFile::Remove(bool aRecursive) Line 2332	C++
xul.dll!nsMsgDatabase::CheckForErrors(nsresult err, bool sync, nsMsgDBService * aDBService, nsIFile * summaryFile) Line 1299	C++
xul.dll!nsMsgDatabase::OpenInternal(nsMsgDBService * aDBService, nsIFile * summaryFile, bool aCreate, bool aLeaveInvalidDB, bool sync) Line 1228	C++
xul.dll!nsMsgDatabase::Open(nsMsgDBService * aDBService, nsIFile * aFolderName, bool aCreate, bool aLeaveInvalidDB) Line 1196	C++
xul.dll!nsMailDatabase::Open(nsMsgDBService * aDBService, nsIFile * aSummaryFile, bool aCreate, bool aUpgrading) Line 52	C++
xul.dll!nsMsgDBService::OpenMailDBFromFile(nsIFile * aFolderName, nsIMsgFolder * aFolder, bool aCreate, bool aLeaveInvalidDB, nsIMsgDatabase * * pMessageDB) Line 357	C++
xul.dll!nsMailboxUrl::GetMsgHdrForKey(unsigned int msgKey, nsIMsgDBHdr * * aMsgHdr) Line 190	C++
xul.dll!nsMailboxUrl::GetMessageHeader(nsIMsgDBHdr * * aMsgHdr) Line 236	C++
xul.dll!nsMailboxProtocol::SetupMessageExtraction() Line 417	C++
xul.dll!nsMailboxProtocol::Initialize(nsIURI * aURL) Line 119	C++
xul.dll!nsMailboxService::NewChannel2(nsIURI * aURI, nsILoadInfo * aLoadInfo, nsIChannel * * _retval) Line 609	C++
xul.dll!nsIOService::NewChannelFromURIWithProxyFlagsInternal(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsILoadInfo * aLoadInfo, nsIChannel * * result) Line 799	C++
xul.dll!nsIOService::NewChannelFromURIWithProxyFlags2(nsIURI * aURI, nsIURI * aProxyURI, unsigned int aProxyFlags, nsIDOMNode * aLoadingNode, nsIPrincipal * aLoadingPrincipal, nsIPrincipal * aTriggeringPrincipal, unsigned int aSecurityFlags, unsigned int aContentPolicyType, nsIChannel * * result) Line 890	C++
xul.dll!nsIOService::NewChannelFromURI2(nsIURI * aURI, nsIDOMNode * aLoadingNode, nsIPrincipal * aLoadingPrincipal, nsIPrincipal * aTriggeringPrincipal, unsigned int aSecurityFlags, unsigned int aContentPolicyType, nsIChannel * * result) Line 676	C++
xul.dll!NS_NewChannelInternal(nsIChannel * * outChannel, nsIURI * aUri, nsINode * aLoadingNode, nsIPrincipal * aLoadingPrincipal, nsIPrincipal * aTriggeringPrincipal, unsigned int aSecurityFlags, unsigned int aContentPolicyType, nsILoadGroup * aLoadGroup, nsIInterfaceRequestor * aCallbacks, unsigned int aLoadFlags, nsIIOService * aIoService) Line 171	C++
xul.dll!NS_NewChannelWithTriggeringPrincipal(nsIChannel * * outChannel, nsIURI * aUri, nsINode * aLoadingNode, nsIPrincipal * aTriggeringPrincipal, unsigned int aSecurityFlags, unsigned int aContentPolicyType, nsILoadGroup * aLoadGroup, nsIInterfaceRequestor * aCallbacks, unsigned int aLoadFlags, nsIIOService * aIoService) Line 95	C++
xul.dll!NewImageChannel(nsIChannel * * aResult, bool * aForcePrincipalCheckForCacheEntry, nsIURI * aURI, nsIURI * aInitialDocumentURI, int aCORSMode, nsIURI * aReferringURI, mozilla::net::ReferrerPolicy aReferrerPolicy, nsILoadGroup * aLoadGroup, const nsCString & aAcceptHeader, unsigned int aLoadFlags, unsigned int aPolicyType, nsIPrincipal * aLoadingPrincipal, nsISupports * aRequestingContext, bool aRespectPrivacy) Line 774	C++
xul.dll!imgLoader::LoadImage(nsIURI * aURI, nsIURI * aInitialDocumentURI, nsIURI * aReferrerURI, mozilla::net::ReferrerPolicy aReferrerPolicy, nsIPrincipal * aLoadingPrincipal, nsILoadGroup * aLoadGroup, imgINotificationObserver * aObserver, nsINode * aContext, nsIDocument * aLoadingDocument, unsigned int aLoadFlags, nsISupports * aCacheKey, unsigned int aContentPolicyType, const nsAString_internal & initiatorType, imgRequestProxy * * _retval) Line 2162	C++
xul.dll!nsContentUtils::LoadImage(nsIURI * aURI, nsINode * aContext, nsIDocument * aLoadingDocument, nsIPrincipal * aLoadingPrincipal, nsIURI * aReferrer, mozilla::net::ReferrerPolicy aReferrerPolicy, imgINotificationObserver * aObserver, int aLoadFlags, const nsAString_internal & initiatorType, imgRequestProxy * * aRequest, unsigned int aContentPolicyType) Line 3130	C++
xul.dll!nsDocument::MaybePreLoadImage(nsIURI * uri, const nsAString_internal & aCrossOriginAttr, mozilla::net::ReferrerPolicy aReferrerPolicy) Line 9913	C++
xul.dll!nsHtml5TreeOpExecutor::PreloadImage(const nsAString_internal & aURL, const nsAString_internal & aCrossOrigin, const nsAString_internal & aSrcset, const nsAString_internal & aSizes, const nsAString_internal & aImageReferrerPolicy) Line 962	C++
xul.dll!nsHtml5SpeculativeLoad::Perform(nsHtml5TreeOpExecutor * aExecutor) Line 38	C++
xul.dll!nsHtml5TreeOpExecutor::FlushSpeculativeLoads() Line 299	C++
xul.dll!nsHtml5LoadFlusher::Run() Line 145	C++
xul.dll!nsThread::ProcessNextEvent(bool aMayWait, bool * aResult) Line 1073	C++
xul.dll!NS_ProcessNextEvent(nsIThread * aThread, bool aMayWait) Line 290	C++
xul.dll!mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate * aDelegate) Line 98	C++
xul.dll!MessageLoop::RunInternal() Line 235	C++
xul.dll!MessageLoop::RunHandler() Line 229	C++
xul.dll!MessageLoop::Run() Line 209	C++
xul.dll!nsBaseAppShell::Run() Line 158	C++
xul.dll!nsAppShell::Run() Line 264	C++
xul.dll!nsAppStartup::Run() Line 285	C++
xul.dll!XREMain::XRE_mainRun() Line 4369	C++
xul.dll!XREMain::XRE_main(int argc, char * * argv, const nsXREAppData * aAppData) Line 4473	C++
xul.dll!XRE_main(int argc, char * * argv, const nsXREAppData * aAppData, unsigned int aFlags) Line 4581	C++
thunderbird.exe!00a42dcf()	Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for thunderbird.exe]	
[External Code]	

I took a copy of Drafts and Drafts.msf before the deletion. Then I restored Drafts.msf and clicked on the Drafts folder. The folder opened and no further deletion took place. So the drafts folder isn't corrupt at all.

I think what happens is that in rare cased the internal logic becomes confused and checks a message file against a summary file that isn't related.

This is 100% reproducible. Every time I click on the newest message in the inbox, Drafts.msf is deleted.

Kent, this is really quite a severe problem. Can you help me?
Flags: needinfo?(rkent)
Keywords: dataloss
Summary: Drafts folder corrupted. Superseded messages showing up as new, not replies → Drafts.msf deleted when clicking on unrelated folder, for example Inbox
Perhaps I should mention that the error returned from the check was
0x80550005 - NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE
and that the message that causes the deletion of the Drafts.msf contains a reference to the drafts folder:

<img src=3D"mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jazz.jo=
rgk.com/Drafts?number=3D10&C=3D3FB5FYNAY98WO&R=3D3MHCTGXCZTDTX&T=3DE&U=3Dht=
tps%3A%2F%2Fimages-eu.ssl-images-amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftrans=
p.gif&A=3DBF66D29TTSPDIYLGNA4KSWIVXLAA&H=3DAXIHIYWBCBUUPCNNDOYD01CYHC4A"></=
img>
Summary: Drafts.msf deleted when clicking on unrelated folder, for example Inbox → Drafts.msf deleted when clicking on a specific message in an unrelated folder
OK, I moved the message that causes the Drafts.msf folder deletion to a different folder and viewing it in the new folder still deletes Drafts.msf.

So this has really become a security problem. Viewing a (malformed) message from an (involuntary) attacker will corrupt the TB message store. No good.
Group: mail-core-security
More details.

The original message contained:
    <img
src="https://www.amazon.de/gp/r.html?C=3FB5FYNAY98WO&amp;R=3MHCTGXCZTDTX&amp;T=E&amp;U=https%3A%2F%2Fimages-eu.ssl-images-amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif&amp;A=BF66D29TTSPDIYLGNA4KSWIVXLAA&amp;H=AXIHIYWBCBUUPCNNDOYD01CYHC4A">

This I see when replying (using add-on ThunderHTMLedit to view the HTML source while editing):
      <img moz-do-not-send="true"
src="https://www.amazon.de/gp/r.html?C=3FB5FYNAY98WO&amp;R=3MHCTGXCZTDTX&amp;T=E&amp;U=https%3A%2F%2Fimages-eu.ssl-images-amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif&amp;A=BF66D29TTSPDIYLGNA4KSWIVXLAA&amp;H=AXIHIYWBCBUUPCNNDOYD01CYHC4A">

Somehow I managed to send this (this is in the sent message, comment #31 contained a excerpt from a further reply):
 <img
src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jazz.jorgk.com/Drafts?number=10&amp;C=3FB5FYNAY98WO&amp;R=3MHCTGXCZTDTX&amp;T=E&amp;U=https%3A%2F%2Fimages-eu.ssl-images-amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif&amp;A=BF66D29TTSPDIYLGNA4KSWIVXLAA&amp;H=AXIHIYWBCBUUPCNNDOYD01CYHC4A"
        moz-do-not-send="true">

And when viewing this message or any further e-mail in the conversation, the Drafts.msf gets deleted.

I think it's bad enough that a message with the reference to an internal mailbox got sent. Even worse is that viewing that message later actively destroys the internal message store.
Status: REOPENED → NEW
OK, you're all bored by now ;-)

I went through my entire message store looking for messages that contain "src.*mailbox.*Drafts".

I found a few, 49 in my local folders. Then I went to visit one of the folders that contains such messages and started viewing messages. Within 15 seconds the alarm bells of the script I am using to monitor Draft.msf removals went off.

If I wanted to bore you even more, I could go thought all the messages I found and relate them to the dates of the comments made in this bug. I will save me the work since I think I made my point loud and clear:

Viewing messages can corrupt whichever mailbox the message happens to reference. Most likely this is a Drafts folder.
Summary: Drafts.msf deleted when clicking on a specific message in an unrelated folder → Drafts.msf deleted when viewing a message that contains a reference to the drafts folder like img src="mailbox:///.../Drafts?number=... in an unrelated folder
Severity: major → critical
Wayne, this already fails in TB 38. Since the bug is now access restricted and not so easy to reproduce, no one will find a regression window here. It's just forward debugging to fix it.

Let me guess: Somehow we try to access a message that is no longer there, an old draft. I have occurrences that look like:
src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Drafts?number=1112591&amp;avatarId=10128"
See the high number 1112591 pointing to a draft message in a drafts folder which hasn't been compacted for a while and contains thousands of superseded messages.

So we look for the message which is no longer there, and conclude that the .msf file is invalid instead of just detecting the situation. Anyway, just a guess without having debugged it further. It took seven months to find!!
Edit the attached e-mail so the image source points to the physical location of your drafts folder (or any other folder) which you wish to corrupt.

Then import the message and view it.

Result: The MSF file of the folder pointed to in the message is deleted although it was not corrupt or defective.
Adapted my test to

src="mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/mail.your-server-1.de/HUHU?number=26743660&amp;avatarId=10142"

Result: HUHU.msf gets deleted.
I've added some debug. This is what I see:

==== OpenMDB of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf| returned 0
===== Entering nsMailDatabase::GetSummaryValid
===== Leaving nsMailDatabase::GetSummaryValid with since !m_folder
==== setting NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE, rv=80070057, valid=0
***** |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf|

The line with the ***** is not in the patch. I print that in the Remove(). So the result is that due some logic error a perfectly valid MSF file is deleted whose folder is referenced in a message in another folder.

Terrible.

This is a case for Kent or Aceman.
Since I don't know anything about this, the only thing I can propose is to ignore the error condition and keep going. This of course could hide a more severe logic error elsewhere. I'll leave it to the database masters to figure out a better fix.

With this patch. I get this on the debug console:

[6856] ###!!! ASSERTION: couldn't get message header: 'false', file c:/mozilla-source/comm-central/mailnews/local/src/nsMailboxProtocol.cpp, line 425
[6856] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file c:/mozilla-source/comm-central/mailnews/local/src/nsMailboxService.cpp, line 609
[6856] WARNING: nsMailDatabase::GetSummaryValid(): Folder not set, assuming valid database: file c:/mozilla-source/comm-central/mailnews/db/msgdb/src/nsMailDatabase.cpp, line 113
[6856] ###!!! ASSERTION: couldn't get message header: 'false', file c:/mozilla-source/comm-central/mailnews/local/src/nsMailboxProtocol.cpp, line 425

I'm not sure what the assertions are trying to tell us. Maybe that I'm trying to access a message that doesn't exist. Not a surprise with:
src="mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.testing/Mail/mail.your-server-1.de/HUHU?number=26743660&amp;avatarId=10142"
Attachment #8755170 - Flags: feedback?(rkent)
Looks like you've done some great work here, Jorgk. I will try to look at this, but no promises when.
Maybe
ASSERTION: couldn't get message header: 'false', file c:/mozilla-source/comm-central/mailnews/local/src/nsMailboxProtocol.cpp, line 425
has something to do with it.

Looks like
      rv = msgUrl->GetMessageHeader(getter_AddRefs(msgHdr));
      if (NS_SUCCEEDED(rv) && msgHdr)
failed, and that might be the reason why m_folder is not set later on. Haven't looked into it, just guessing ;-)
Great work tracking it down! I can confirm the deletion also on Linux.

I have not the slightest idea why we interpret the link in src as a path into our database and check its validity. But it can't be random so there must be a use to it. Maybe the link references some parts (in a multipart msg) while the message is drafted?

(In reply to Jorg K (PTO during summer, NI me) from comment #37)
> Adapted my test to
> 
> src="mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.
> testing/Mail/mail.your-server-1.de/HUHU?number=26743660&amp;avatarId=10142"

Is the number after "number=" referring to anything useful? Is it the draft msg key, or the offset in the file? But then what is the avatarId ?

So the bug seems to be that even if the folder identifier is valid (the path to the folder, not the number id) we consider the database invalid. We should return that the database is valid, but then still return failure at "couldn't get message header:". Even though it is not sure why that is an assertion. Maybe that such a link should never exist outside of the Drafts folder? But I have tried to put the sample message into the Drafts folder. Viewing it still wipes the Drafts.msf. So the link does not suddenly work (behave differently) if put in Drafts folder itself.

I think we should add some debugging output into nsMsgDatabase object to the places where m_folder is initialized to see when/why it isn't inited in this case. Because we do have a folder (the Drafts), we just do not have the particular message.
(In reply to :aceman from comment #43)
> Great work tracking it down!
I just hate my drafts folder going bang and 123 superseded drafts reappearing.

Thanks for confirming it, so it's not my system silently eating MSF files ;-)

> I have not the slightest idea why we interpret the link in src as a path
> into our database and check its validity.
Well, under some circumstances images a referenced that way.

> > src="mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/testing.
> > testing/Mail/mail.your-server-1.de/HUHU?number=26743660&amp;avatarId=10142"
> Is the number after "number=" referring to anything useful? Is it the draft
> msg key, or the offset in the file? But then what is the avatarId ?
I can't imagine 26743660 ever being a valid message key. The avatarId must have come from the original message being replied to. I think it has no importance. This is the original snippet:
                                <img moz-do-not-send="true"
                                  id="email-avatar"
src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jorgk.jorgk.com/Drafts?number=26743660&amp;avatarId=10142"
                                  alt="" style="padding:0;margin: 0 16px
                                  16px 0;" height="48" align="left"
                                  border="0" width="48">

But I have others, like this one:
      <img moz-do-not-send="true"
src="mailbox:///D:/MAIL-THUNDERBIRD/jorgk.default/Mail/jazz.jorgk.com/Drafts?number=24777&amp;C=3FB5FYNAY98WO&amp;R=3MHCTGXCZTDTX&amp;T=E&amp;U=http%3A%2F%2Fimages-eu.amazon.com%2Fimages%2FG%2F01%2Fnav%2Ftransp.gif&amp;A=SHDG3VSIKX98SBHNEIRZG85R1BCA&amp;H=SMUQCKNPPLAKNN2A5KYTBP9GFAWA">

It is a secondary issue why this strange image source was created in the first place.

> I think we should add some debugging output into nsMsgDatabase object to the
> places where m_folder is initialized to see when/why it isn't inited in this
> case. Because we do have a folder (the Drafts), we just do not have the
> particular message.
Agreed. Who is we? I've tried to look for m_folder being set and at first and second glance found nothing obvious. Maybe you have more experience in this area?
I have not been able to duplicate the deleted file. However, the caller of GetSummaryValid does not check error return, and when

  if (!m_folder)
    return NS_ERROR_NULL_POINTER;

occurs, it just used an uninitialized valid, which in my system is true but in other circumstance I can imagine would be false, and the file gets deleted.

Really we should not be deleting the message summary file as a consequence of GetMsgHdrForKey not finding the key.
"I can't imagine 26743660 ever being a valid message key"  Why not? Key used to be offset into the file, and could be anything between 0 and 4 GB
Flags: needinfo?(rkent)
It would be helpful if I could see the stack trace that leads to file deletion, so that I can confirm that I am looking at the right execution path in trying to plan a way forward.

But it sure seems to me that GetMsgHdrForKey is 1) opening a mailDB without bothering to identify the corresponding message folder and therefore getting m_folder set (which is guaranteed to fail, though whether that fail results in a detected failure is not properly defined), AND setting the flag saying to delete the folder if the open fails.

But what I am seeing is a little different than the problem you are describing, as this looks to me like it has nothing to do with an invalid key. That's why I need to see the actual stack that leads to a deleted database. If you've already reported that, point me to it please, it was not obvious to be skimming the comments here.
Flags: needinfo?(rkent)
The stack trace is in comment #30. Since I can reproduce this with a few clicks (switching folders and finally clicking onto the folder and viewing the message that causes the deletion), I can dump out anything you want additionally.

Let me quote from the stack trace in comment #30 (complete stack trace above):
xul.dll!nsLocalFile::Remove(bool aRecursive) Line 2332	C++
xul.dll!nsMsgDatabase::CheckForErrors(nsresult err, bool sync, nsMsgDBService * aDBService, nsIFile * summaryFile) Line 1299	C++
xul.dll!nsMsgDatabase::OpenInternal(nsMsgDBService * aDBService, nsIFile * summaryFile, bool aCreate, bool aLeaveInvalidDB, bool sync) Line 1228	C++
xul.dll!nsMsgDatabase::Open(nsMsgDBService * aDBService, nsIFile * aFolderName, bool aCreate, bool aLeaveInvalidDB) Line 1196	C++
xul.dll!nsMailDatabase::Open(nsMsgDBService * aDBService, nsIFile * aSummaryFile, bool aCreate, bool aUpgrading) Line 52	C++
xul.dll!nsMsgDBService::OpenMailDBFromFile(nsIFile * aFolderName, nsIMsgFolder * aFolder, bool aCreate, bool aLeaveInvalidDB, nsIMsgDatabase * * pMessageDB) Line 357	C++
xul.dll!nsMailboxUrl::GetMsgHdrForKey(unsigned int msgKey, nsIMsgDBHdr * * aMsgHdr) Line 190	C++

For example, I could dump out the arguments in the call to GetMsgHdrForKey(). If you give me a short snippet dump out aMsgHdr, it will be quicker ;-)
Here comes another debug patch that shows the cause of action. This is the debug that I see. I added some comments. I still don't see where the m_folder gets set in the "good" case.

Kent, full stack trace in comment #30 and a snipped in comment #48.

Here now the debug:

Opening the folder "AAA Message will delete" that contains the fatal message:
==== OpenMDB of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\Local Folders\AAA Message will delete.msf| returned 0
===== Entering nsMailDatabase::GetSummaryValid

The next line will only be reached when m_folder is set. So in the good case, it is set.
===== nsMailDatabase: m_folder->GetMsgStore returned 0, name AAA Message will delete
===== Entering nsMsgBrkMBoxStore::IsSummaryFileValid
===== nsMsgBrkMBoxStore::IsSummaryFileValid: after arg check
===== Leaving nsMsgBrkMBoxStore::IsSummaryFileValid with NS_OK
===== Leaving nsMailDatabase::GetSummaryValid with 0
==== CheckForErrors of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\Local Folders\AAA Message will delete.msf| returned 0
===== Entering nsMailDatabase::GetSummaryValid
===== nsMailDatabase: m_folder->GetMsgStore returned 0, name AAA Message will delete
===== Entering nsMsgBrkMBoxStore::IsSummaryFileValid
===== nsMsgBrkMBoxStore::IsSummaryFileValid: after arg check
===== Leaving nsMsgBrkMBoxStore::IsSummaryFileValid with NS_OK
===== Leaving nsMailDatabase::GetSummaryValid with 0

This seems to fetch the fatal message from the folder:
=== nsMailboxUrl::GetMsgHdrForKey: key 3, filepath AAA Message will delete
=== nsMailboxUrl::GetMsgHdrForKey: after msgDBService->OpenMailDBFromFile 0
=== nsMailboxUrl::GetMsgHdrForKey: after mailDB->GetMsgHdrForKey 0
=== nsMailboxUrl::GetMsgHdrForKey: returning 0
=== nsMailboxUrl::GetMsgHdrForKey: key 3, filepath AAA Message will delete
=== nsMailboxUrl::GetMsgHdrForKey: after msgDBService->OpenMailDBFromFile 0
=== nsMailboxUrl::GetMsgHdrForKey: after mailDB->GetMsgHdrForKey 0
=== nsMailboxUrl::GetMsgHdrForKey: returning 0
=== nsMailboxUrl::GetMsgHdrForKey: key 3, filepath AAA Message will delete
=== nsMailboxUrl::GetMsgHdrForKey: after msgDBService->OpenMailDBFromFile 0
=== nsMailboxUrl::GetMsgHdrForKey: after mailDB->GetMsgHdrForKey 0
=== nsMailboxUrl::GetMsgHdrForKey: returning 0

This seems to try to access the message referenced in the fatal message. The reference is to folder HUHU and key 26743660:
=== nsMailboxUrl::GetMsgHdrForKey: key 26743660, filepath HUHU
==== OpenMDB of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf| returned 0
===== Entering nsMailDatabase::GetSummaryValid
===== Leaving nsMailDatabase::GetSummaryValid since !m_folder
==== setting NS_MSG_ERROR_FOLDER_SUMMARY_OUT_OF_DATE, rv=80070057, valid=0
***** |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf|
==== CheckForErrors of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf| returned 80550005
=== nsMailboxUrl::GetMsgHdrForKey: after msgDBService->OpenMailDBFromFile 80550005
=== nsMailboxUrl::GetMsgHdrForKey: else branch
=== nsMailboxUrl::GetMsgHdrForKey: returning 0
Attachment #8755136 - Attachment is obsolete: true
Let me fantasize a little:

Normally, when we open a message, we open the folder containing the message and then view the message. Somehow somewhere this must set the ominous m_folder.

Here we have the case that we open a folder XX which contains a message xx which references a message yy in another folder YY. When trying to access this second folder YY and message yy, we don't have m_folder set.

Note that nsMailboxUrl::GetMsgHdrForKey() calls OpenMailDBFromFile() here
https://dxr.mozilla.org/comm-central/source/mailnews/local/src/nsMailboxUrl.cpp#190
with the second argument (folder) set to nullptr.
As much as I tried to set something useful in m_folder, I failed. Debug with this patch:

=== nsMailboxUrl::GetMsgHdrForKey: key 3, filepath AAA Message will delete
=== can't get folder from *aMsgHdr==NULL
=== nsMailboxUrl::GetMsgHdrForKey: after msgDBService->OpenMailDBFromFile 0
=== nsMailboxUrl::GetMsgHdrForKey: after mailDB->GetMsgHdrForKey 0
=== nsMailboxUrl::GetMsgHdrForKey: returning 0
=== nsMailboxUrl::GetMsgHdrForKey: key 26743660, filepath HUHU
=== can't get folder from *aMsgHdr==NULL
==== nsMsgDBService::OpenMailDBFromFile setting m_folder to 00000000
==== OpenMDB of |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf| returned 80550005
***** |C:\Users\jorgk\AppData\Roaming\Thunderbird\Profiles\testing.testing\Mail\mail.your-server-1.de\HUHU.msf|
Comment on attachment 8755170 [details] [diff] [review]
Ignoring the !m_folder condition.

Review of attachment 8755170 [details] [diff] [review]:
-----------------------------------------------------------------

I agree that this is the correct solution. But the problem with all of this backend code is that the design has so many special cases, and side effects from methods, that it is really hard to know whether some change is going to cause some unexpected regression.

I would do one change. We know of one condition where the m_folder is not set, and that is when the message database is being opened from a URL. Actually even OpenMailDBFromFile delays setting m_folder until AFTER the Open has returned successfully. So null m_folder is an expected condition. I don't think we should be generating a warning for an expected condition.

So please remove that warning, and replace it just with a comment that null m_folder is an expected condition, but perhaps we should take some effort to pass the folder forward so that it is available.

You did not ask for r+ but I will give it if you want to land this.
Attachment #8755170 - Flags: review+
Attachment #8755170 - Flags: feedback?(rkent)
Attachment #8755170 - Flags: feedback+
Thanks.(In reply to Kent James (:rkent) from comment #52)
> So please remove that warning, and replace it just with a comment that null
> m_folder is an expected condition, 
OK. Will do.

> but perhaps we should take some effort to
> pass the folder forward so that it is available.
Can you please elaborate. Pass the folder from where? I tried as much as I could, see comment #51.

> You did not ask for r+ but I will give it if you want to land this.
Thanks. So I can either land it with the warning removed and the comment added, or we take it a step further to pass the folder, but I'd need your guidance on that.
I do not recommend that you try to pass the folder any more than you have already done at the moment. I would just add a comment that it should probably be done so that in the future we will understand that allowing null m_folder is a concession and not a design decision.
Flags: needinfo?(rkent)
Removed the warning and added a *big* comment.
Carrying forward Kent's r+.

This should be uplifted after riding the trains for a while.

[Approval Request Comment]
Regression caused by (bug #): Bug 402392
http://hg.mozilla.org/comm-central/rev/097bc36f180d#l47.485
User impact if declined: Just terrible. MSF files mysteriously get deleted which corrupts perfectly good folders.
Testing completed (on c-c, etc.): Manual.
Risk to taking this patch (and alternatives if risky):
Risk as per comment #52. Therefore it should ride the trains for a while.
Attachment #8755170 - Attachment is obsolete: true
Attachment #8757608 - Flags: review+
Attachment #8757608 - Flags: approval-comm-esr45?
Attachment #8757608 - Flags: approval-comm-beta?
Attachment #8757608 - Flags: approval-comm-aurora+
https://hg.mozilla.org/comm-central/rev/a4a6d230a27c
(Checked in with one trailing space, sorry about that).
Status: NEW → RESOLVED
Closed: 5 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 49.0
Assignee: nobody → mozilla
This is a bug whose risk it is really hard to evaluate. I'm leaning toward not including it in beta47 (and therefore not in 45.2 release) and let it ride the TB 48 beta train for a few weeks. Any objections? I'd like to get this fixed, but it has been around for while so another few weeks of evaluation is good.
Sure. I've been seeing this since TB 43. I don't understand why this hasn't been reported before.

We still don't know how these "killer messages" are created in the first place, see bug 1276419.

Kent, perhaps you could grep through your mail store for "src.*mailbox.*Drafts" to see whether you have any of those messages.
Group: mail-core-security → core-security-release
Attachment #8757608 - Flags: approval-comm-beta? → approval-comm-beta+
Changed your mind on inclusion in TB 47?
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #60)
> Changed your mind on inclusion in TB 47?

I suppose that I did.
In that case it would be great to paste the changeset here ;-)
https://hg.mozilla.org/releases/comm-beta/rev/0afa3cc08047
(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #59)
> Sure. I've been seeing this since TB 43. I don't understand why this hasn't
> been reported before.

Please see bug 482836 if that isn't a prior report of this :)
Duplicate of this bug: 482836
Although I pushed this to beta 47, let's hold off for now pushing it to release based om comment 58.
See Also: → 1276419
Comment on attachment 8757608 [details] [diff] [review]
Ignoring the !m_folder condition (v2).

This was in beta 47, so should be OK to push to esr45
Attachment #8757608 - Flags: approval-comm-esr45? → approval-comm-esr45+
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.