Closed Bug 536676 Opened 10 years ago Closed 10 years ago
msg list data disappears until I navigate away from inbox to another folder then come back
375.06 KB, image/png
295.32 KB, image/png
5.67 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52) Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/20091204 Thunderbird/3.0 Vista Ultimate 64 bit. Updated to TB 3.0 and I find that occasionally, the Subject, From and Date data disappear from the msg list. Location data (inbox) remains in the display. If I highlight one of the blank msg lines, no msg appears in the msg pane. If I navigate to another folder and then come right back to the inbox, all the data reappears. There is an image of the problem in the link referenced above. This has happened two or three times since I upgraded to TB3.0. I am not sure yet how to reproduce it. Reproducible: Sometimes Default theme Smart folders
Using Pop or imap ?
And while I'm asking question - does it happen in -safemode too (http://kb.mozillazine.org/Safe_mode)?
Using Pop. I haven't tried safe mode. I normally use smart folders. It happened again recently and I changed to all folders, then clicked on the inbox and everything came back. I switched back to smart folders and everything was normal. What seems to happen is that all the messages are there, then as I bring the cursor up to the list pane, the msgs disappear as the cursor touches them. Very strange. I've not seen this happen on my laptop running XP. I have not seen a pattern as to what triggers it on the Vista machine.
I have the same problem with TB 3.0.1 on Mac OS X 10.6.2. I am not sure what triggers the lines of data (at the bottom of the inbox) to disappear, but I can confirm that clicking on another folder and then clicking back on the inbox makes the missing email subject, date etc reappear. I have screenshots that show the missing data and the restored data after clicking away and then back. I'll see if I can add these to this report. I use POP and my inbox is a smart folder (I think - I have 2 email accounts and incoming emails appear together in the inbox with the vanishing problem).
This attachment refers to my note confirming that I have the same problem as already report on Mac OS X. The missing lines of data are at the bottom of the inbox and they are new messages. I will upload a second shot showing what the screen looks like after clicking elsewhere (on another folder) and then clicking back on the inbox.
Second screenshot showing the correct view of the inbox after clicking on another folder and then clicking back on the inbox.
I have now confirmed the erratic bug on my laptop running XP/pro.sp3 as well as a fresh install of Windows 7 Home Premium/64 bit (which replaced Vista/64 bit on the original computer as reported above).
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) > Gecko/20091201 Firefox/3.5.6 (.NET CLR 3.5.30729) > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:18.104.22.168) > Gecko/20091204 Thunderbird/3.0 > > Vista Ultimate 64 bit. > > Updated to TB 3.0 and I find that occasionally, the Subject, From and Date data > disappear from the msg list. Location data (inbox) remains in the display. If I > highlight one of the blank msg lines, no msg appears in the msg pane. If I > navigate to another folder and then come right back to the inbox, all the data > reappears. > > There is an image of the problem in the link referenced above. > > This has happened two or three times since I upgraded to TB3.0. I am not sure > yet how to reproduce it. > > Reproducible: Sometimes > > > > > Default theme > Smart folders I have been having the same problem periodically, ever since moving to TB3. This happens on my laptop (Win 7) and my other box (XP 32). Moving the mouse pointer over the message summary line causes the entire line to disappear (location box and everything). Clicking on other messages does NOT cause them to appear in the message pane. TB appears to lock up in terms of handling messages. Deleting a message also does not execute. (I will often try deleting the message I have just read when I notice that this lock-up has occurred, and upon restarting TB the message I was reading/deleting is still there.) I do use smart folders. I can't say that I have tried clicking on a different folder and then back to see if that cleared it up, nor have I tried safe mode. (I will try those things next time it happens; well, safe mode has to be done before it happens, I suppose.) I have noticed that it seems to happen when TB is doing some other process (compacting folders, contacting servers and waiting for response, or something else like that). This is just based on the presence of the green progress bar in the bottom right of the window.
Oh, this still happens after the most recent release, 3.0.2 (just installed it yesterday).
Dang it, more thoughts occurring (obviously slowly...) I have a combination of IMAP and POP accounts that it is checking and displaying in the main smart view (i.e. the combined inbox view). Any message will disappear (e.g. it isn't ONLY pop summary lines that disappear), but I haven't verified if it is only during the viewing/reading of a IMAP/POP message that the problem begins. (I only use the preview/message view pane to read, I am not creating tabs or separate windows for reading.)
A bit more information now, the following day: Today's occurrence only had emails from my POP account disappearing. This is contrary to what I had said earlier. (I probably just hadn't watched closely enough earlier. :)) Also, the status bar at the bottom of the screen says "Done Compacting". And this problem had come up immediately following my deletion of an email. I don't recall if the email deleted was FROM the same POP account or not. Hmmm...it probably was from that account, because it is the only POP account I have and it wouldn't be compacting a folder from an IMAP inbox. I haven't tried SAFE mode yet. Lastly, this bug appears to be identical to this one: 535516.
Yes, I have some more to say. :) I have made some additional comments in Bug 535516 (it is older and had a good tip: look in Tools -> Error Console). I did find some errors in there after experiencing this bug. Here is what I posted over there: ---------------------------------- I believe that this is tied to the compaction of the folder. I have my compaction limit set fairly high, 1000KB. So I don't see the error every time I use Thunderbird. Here are the errors I found in the error console: Warning: Expected ':' but found 'repeat-x'. Declaration dropped. Source File: mailbox:///C|/Users/Justin/AppData/Roaming/Thunderbird/Profiles/7veroqry.default/Mail/mail.comcast.net/Inbox?number=3083869 Line: 0 Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgDBView.getMsgHdrsForSelection]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: chrome://messenger/content/folderDisplay.js :: FolderDisplayWidget_get_selectedMessages :: line 1894" data: no] Source File: chrome://messenger/content/folderDisplay.js Line: 1894 2010-02-27 08:10:12 gloda.index_msg WARN Observed header that claims to be gloda indexed but that gloda has never heard of during compaction. In folder: mailbox://email@example.com/Inbox sketchy key: 1992358 subject: J. Tillman: Fleet Foxes' Drummer Takes A Solo 2010-02-27 08:10:15 gloda.index_msg ERROR Exception while attempting to mark message with gloda state afterdb commit [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgDBHdr.getUint32Property]" nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)" location: "JS frame :: file:///C:/Program%20Files%20(x86)/Mozilla%20Thunderbird/modules/gloda/index_msg.js :: PendingCommitTracker_commitCallback :: line 172" data: no] An interesting note: the message that it says has the bad header is NOT the message I was trying to delete. The message it says is bad is one that has been in my inbox for a while, and it hasn't been deleted (it is still there). I will watch the error log when this happens to see if it is the same message each time. ------------------------------------------ (end of other posting)
Update: for the last day or two, I've been running TB 3.02 in TB safe mode. Today I saw one instance which was similar to the disappearing msgs in regular TB, but it was also different in some ways. There were several msgs that disappeared from the list, but I was still able to work with TB. If not in safe mode, I have to navigate away and then back to smart folders to regain control. Under TB safe mode, I was still able to navigate around and view other msgs when the problem showed itself. But I was able to recover the missing msgs from the list by navigating to another folder (draft, templates, etc) and the back to the smart folder and everything showed up as normal at that point. In TB safe mode, I did not see any msgs disappear as the cursor moved over them as I've seen with normal TB. Then again, I've only used TB safe mode for about 2 days. The disappearing msgs seem to be happening more and more frequently in standard TB mode. Not necessarily every day, but the problem seems to be more common.
Update: I am running in TB safe mode and portions of the msg list disappear again today. This time, it happened right after compacting. The msg that was displayed in the msg pane was still there although in the msg list it was gone. Once I navigated away from that msg and tried another in the list, I could not bring that particular msg back to the msg pane until I navigated to a different folder and then back to the inbox. Any msg that was still showing in the msg list was viewable. Any msg that disappeared was not viewable until I navigated to a different folder then back to the inbox.
Further update: When the problem appears, I am unable to write a new message. I can click Get Mail and it appears to function properly. But if I click Write, nothing happens. Once I navigate away from the inbox and then return to it, all functions appear normal.
Oops.. running TB 3.03 now.
This problem appears most often after auto-compacting has occurred.
Compacting local folders can change the message keys for messages, and if those messages are displayed in a saved search folder, we'll be unable to display those message headers. So smart folders/saved search folders need to be told about compacting, and rebuild up their contents when the compact is done. I'll take this - I'll try to fix it for beta 2, but I'll put it in the rc1 bucket so dmose's head doesn't explode :-)
Assignee: nobody → bienvenu
Status: UNCONFIRMED → ASSIGNED
blocking-thunderbird3.1: --- → rc1+
Ever confirmed: true
Just to clarify, I have not seen this associated with a search folder. In my case, this has strictly occurred when looking at the inbox. I have compacting set to trigger at 100kb. Should that be set higher?
The smart inbox is a search folder. You are in the smart inbox when you see this happen, right? I'd set compacting a lot higher, 1MB or so.
Yes, I am using smart folders when I see the problem. OK, I was using the suggested values from this article: http://kb.mozillazine.org/Compacting_folders I can change it to 1 MB.
In general, we do rebuild the view when an underlying local folder is compacted, but perhaps we're not getting the notification in some scenarios (e.g., the background compact).
I've noticed there are times when the msg list will disappear when I navigate back to TB after browsing the 'net. As always, a quick click on another folder and then a click on the inbox brings everything back.
The issue is that when we get a foldercompacted notification, it's too late to try to save and restore the selection, because the db(s) underlying the view are already invalid, as are the message headers. Because we don't catch the exception trying to save the selection, we completely fail to rebuild the view, so we're left in view limbo. This patch at least allows the view rebuilding to go on as intended, though the selection won't be restored. Figuring out how to save and restore the selection correctly in this case would entail saving it when the compaction starts, not when it ends. And of course, a mozmill test for this would be good.
This is less than ideal, but it's so much better than what happens today to poor pop3 users.
Comment on attachment 440916 [details] [diff] [review] fix with mozmill test An mc.sleep(0) is okay to spin the event loop, but mc.sleep(1000) is not cool, man... :) Please reduce the latter to the former and if it breaks the test, add a more clever blocking wait... Please reduce the message count to 2 from 4 since you only need 2 and it turns out my message generation code is not the fastest thing in our codebase... Please add a comment to your newly added try block that explains why we would expect that to fail. Given that it's a highly technical case, citing the bug number or just including your blurb from comment 24 (with some mention of the saved search complication) would be great.
Attachment #440916 - Flags: review?(bugmail) → review+
this is what I'll check-in.
Whiteboard: [has patch, needs mozmill test] → [ready to land]
fix checked in.
Comment on attachment 441043 [details] [diff] [review] fix addressing comments probably too late for 3.0.5, but I thought I'd ask...
Attachment #441043 - Flags: approval-thunderbird3.0.5?
Attachment #441043 - Flags: approval-thunderbird3.0.5? → approval-thunderbird3.0.6+
Comment on attachment 441043 [details] [diff] [review] fix addressing comments Didn't make 3.0.6, will re-consider for 3.0.7.
Attachment #441043 - Flags: approval-thunderbird3.0.6+ → approval-thunderbird3.0.7?
Hello, For me, this bug is fixed in version 3.1. :) Regards.
Attachment #441043 - Flags: approval-thunderbird3.0.7? → approval-thunderbird3.0.7+
Checked into 1.9.1 with minor bitrot fix: http://hg.mozilla.org/releases/comm-1.9.1/rev/a2b7364fb2b3
Backout out on 1.9.1 due to failure all-around in the push itself. http://hg.mozilla.org/releases/comm-1.9.1/rev/bde712b03c86
Re-landed on 1.9.1: http://hg.mozilla.org/releases/comm-1.9.1/rev/14006d35371c
You need to log in before you can comment on or make changes to this bug.