User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100207 Ubuntu/9.10 (karmic) Namoroka/3.6.2pre Build Identifier: Thunderbird-3.0 3.0.2pre, Gnome (Ubuntu) when I try to "Advance to next unread message" in the next folder it doesn't work and the tab crashes, i.e is closed, when i check the Error console I can see that this message is repeated many times: Error: this.search is null Source File: file:///usr/lib/thunderbird-3.0.2pre/modules/dbViewWrapper.js Line: 756 Reproducible: Always Steps to Reproduce: 1.read the last message in the folder 2.press n-key and Accept in the "Advance to next unread message in XXX" alert Actual Results: the tab is closed Expected Results: load the next unread message

So your steps to reproduce are almost there :-) I'm just missing the part where you open a tab ? Can you also reproduce if you launch ./thunderbird -safe-mode ?

Premise: I have more than one E-mail account Steps to Reproduce: 1. Open Mozilla Thunderbird 2. Read the first message in the first account. 3. (if you press n-key you can advance to next unread message in the same folder) ... 4. Read the last message in the first account.(and press n-key to advance to next unread message in the next folder or account.) the "Advance to next unread message in XXX", where XXX is the name of the next folder, message is shown, so when you Accept-button the tab, where you going to read the next message is closed, and the message is not opened. I try to open in safe mode but it doesn't care, the problem can be reproduced. NOTE: I don't know to speak/write in English, but I am learning, so mi grammar could be ambiguous or wrong. I speak Spanish... :-)

The same issue, but observed only when advancing to a folder belonging to another account, was reported in Bug 538732. A related issue, in Bug 541560. I see this bug also when messages are displayed in a separate window: advancing from one message to another works fine within the same folder (each advance displaying a new message in the same window), but when advancing to a message in another folder, clicking OK to the warning about this advance does not work. Simply nothing happens, and the window remains with the old message displayed. I experience this in TB 3.0.x (under OSX 10.4.11), but not in 3.0b2 (under OSX 10.5.8). I seem to recall that the bug was also in 3.0b3 or b4, but I cannot check that at the moment. I have no extensions installed in any of my TBs. Cheers, Joachim.

Within the past couple of days this bug was also reported twice on the support-thunderbird mailing list, by Brian Kochera (20/2), and by LuKrema (independently, 23/2) who details that he is running 3.0.1, while John Corliss (20/2) informs that he does not see this problem in XP Home SP3.

Confirming "Open in new window" symptoms reported in Comment #3, MacOS 10.5.8. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 Also confirming behavior noted in description with "Open in new tab"; same JS error: Error: this.search is null Source File: file:///Applications/Thunderbird%203.1.1.app/Contents/MacOS/modules/dbViewWrapper.js Line: 756

This looks like a DUP of 514430 -- except that report seems to have some WFMs (but in early 3.0, so maybe it did get broken in 3.0b-something).

ok, now I am using Arch linux, and Gnome as Desktop Enviroment My Thunderbird's versión is: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.11) Gecko/20101019 Lanikai/3.1.5 And I have the same problem...

Some further diagnostics --- I hope it is accurate: I had previously reported that this bug seems to have been introduced at around 3.0b4 (and that I don't see it in 3.0b2 (which is still my main tb). Now I see the bug in 3.0b2 under special circumstances: it happens when Thunderbird thinks there is a given folder with an unread message, but at the moment of moving to that message in that folder, apparently an IMAP query reveals that it was already read (perhaps from another client), and no advancement is made. In this case, pressing 'n' more times does not have any effect, even if there are other folders with unread messages. Once you go back to the message list and press 'n', it works normally again.

The behaviour in comment:3 still occurs for me in Thunderbird 3.1.8.

The following report is appended to the error console when the bug occurs: Error: An error occurred executing the cmd_nextUnreadMsg command: [Exception... "'[JavaScript Error: "SelectFolder is not defined" {file: "chrome://messenger/content/msgViewNavigation.js" line: 242}]' when calling method: [nsIController::doCommand]" nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)" location: "JS frame :: chrome://global/content/globalOverlay.js :: goDoCommand :: line 96" data: yes] Source File: chrome://global/content/globalOverlay.js Line: 100

SelectFolder is not defined : are you reading in a special folder when this occurs ?

(In reply to comment #14) > SelectFolder is not defined : are you reading in a special folder when this > occurs ? No, this occurs for me in all folders.

(In reply to comment #15) > (In reply to comment #14) > > SelectFolder is not defined : are you reading in a special folder when this > > occurs ? > > No, this occurs for me in all folders. Note that, as in comment:3, this happens 100% of the time when the email is open in a separate window, but not when it is in a pane of the main window (i.e. not when the main window is focussed when pressing Space). Perhaps this is a separate bug to the other cases on this ticket apart from comment:3. In particular it can't be related to IMAP (comment:10), since I'm using only POP3.

Note that the behaviour I described is when mailnews.nav_crosses_folders is set to 1 (the default). If I set it to 0, the error occurs in the console and nothing happens. If I set it to 2, there is no error and nothing happens. (That's what I would expect, but it shows that mailnews.nav_crosses_folders is working and the problem is in actually moving to the next message, not in deciding whether to do so.) I tried disabling all add-ons, and that didn't affect anything.

This bug is still present in Thunderbird 5.0

I can replicate it in TB5, too. And wow, is that ever not what I expected to happen. Protz, could you take a look at this, and see if there's something simple we can do to fix it? Ping me on irc for steps to reproduce… Thanks, Blake.

The code that triggers the SelectFolder error was touched in bug 498415 which confirms that this started to fail with 3.0b4. Looking into it.

So it took me one hour diving deep into the depths of the FolderDisplayWidget and its friends to figure out the fix was a three-liner. Classic. Anyway, at least I got a better understanding of how it all works together, and I believe this is the right fix. What this does is: - implement the SelectFolder function that CrossFolderNavigation (from mail/base/content/msgViewNavigation.js) needs; this function wasn't implemented in the standalone message window, - talk to the trimmed down FolderDisplayWidget that lives in messageWindow.js, through its show method, - since gFolderDisplay has a view it initially obtained by cloning the one from the mail3pane that opened it, it can operate on the view, and have it change folders... Or at least that's my understanding of the stuff :-).

Comment on attachment 548729 [details] [diff] [review] A (too?) simple fix This sounds reasonable, but wants a mozmill test.

So I was trying to write a Mozmill test, and I was unable to make it work properly. Turns out there's an issue with the underlying nsMsgDBView (it took me a while to figure that out, though). Here's (attached) the patch with a Mozmill test that will open a standalone message window, with a mc.sleep() big enough for you to try things out. Here's what you can do: - open the first message in a standalone message window, hit "n" enough times to have the popup "advance to the next unread message in FolderWhateverB?", hit yes, and observe the debug information in the console. The nsMsgDBView says that 5 is an invalid index for folder A, while there are actually six messages in folder A... - open the first message in a standalone message window, hit "n" enough times so that all messages in folder A are marked as read, close the standalone message window, open the first message in folder A in a standalone message window, hit "n", witness the call to nsMsgDBView::Navigate fail. I'm kinda confused by this. I'm posting the patch "as-is" (with a lot of debug information), in the hope that it helps someone confirm the diagnosis.

David, any chance you could take a look at this when you have a minute, and tell me whether the issue is in nsMsgDBView or if I'm completely wrong?

So I was wrong all the line. I guess coding on a plane while tired is not the best way to get things done. Sorry for the confusion, this patch should do everything as expected. For the record, since the selection wasn't cleared, if index 5 was selected in folder A, after switching to folder B, we were still expecting index 5 to be selected. I added a couple lines to make sure when we switch to folder B, we're in a state where the _fakeTreeSelection has no messages selected, which makes the DB view happy and behave correctly.

Comment on attachment 549654 [details] [diff] [review] The right patch checked-in 4f6a003e6273 (deferring review to Jim)

Comment on attachment 549654 [details] [diff] [review] The right patch checked-in 4f6a003e6273 Review of attachment 549654 [details] [diff] [review]: ----------------------------------------------------------------- This works for messages opened in the standalone message window, but not for messages opened in a tab, unfortunately.

Comment on attachment 549654 [details] [diff] [review] The right patch checked-in 4f6a003e6273 Changing to r+ after discussion on IRC: this does fix the issue in the standalone message window, but the bug will need to stay open until part 2 (the message tab case) is fixed.

Comment 13 duplicates the exact same details my original bug reported in bug 542161 (2010-01-25 21:24:02 PST), and still unsolved. Shouldn't the solutions get cross-ref'd? Please?

I've just tested this patch in TB-5.0 built from source (comm-miramar). It successfully advances the message being read from one folder to the next with an unread message when the message is in a separate window. BUT it did not advance the Message Selection Highlight (the way you would click on a folder then on a message to view it, making each highlighted) to the local folder containing that next unread message (folder 'b' in your mozmill case) and thus did not open it to show the read and unread messages Subject/From/Date/etc.... So it is happily reading a message from 'b' but showing the folder 'a' summary. IHTH.

This seems to be fixed in Tb8. I checked on Tb 8.0 w/ Windows 7 x64. protz: Did the code change? Can anyone confirm?

Sorry, I just read the white board after submitting my previous comment. It works in the message preview but not for messages in tabs.

Not fixed in TB 8.0 source as compiled on Linux with defaults

Works in TB 8.0 when opening a message in separate window, but still does not work in tabs.

Please don't add comments until you have something new to contribute. The current state of affairs is: The fix works for messages opened in a new window or messages openened in the message preview. The fix does *not* work for messages opened in a tab. Also, this fix has not been landed yet, so you won't see it neither in a released version nor in a self-compiled one.

I'm using TB 8.0 and it seems to work as expected. No problems as yet.

FYI, still broken in 14 Release: Name= Thunderbird Version= 14.0 User Agent= Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120713 Thunderbird/14.0 Profile Directory= (Local drive) Application Build ID= 20120713141924

FYI, still broken in current TB. If I use a decent folder structure (i.e. subfolders), it takes me several times of pressing "n" to actually arrive at the next unread, with the number of keypresses being determined by the number of levels of subfolders to descend into. *not* amused.