545218 - "Advance to next unread message" doesn't work in standalone message window

Status: RESOLVED FIXED

(Thunderbird :: Message Reader UI, defect)

Description

[jaao_death]

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

Comment 1

[Ludovic Hirlimann [:Usul]]

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 ?

Comment 2

[jaao_death]

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... :-)

Comment 3

[Joachim Kock]

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.

Comment 4

[Joachim Kock]

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.

Comment 5

[Michael A. Pasek]

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

Comment 6

[Michael A. Pasek]

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).

Comment 9

[jaao_death]

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...

Comment 10

[Joachim Kock]

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.

Comment 12

[Daira Hopwood]

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

Comment 13

[Daira Hopwood]

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

Comment 14

[Ludovic Hirlimann [:Usul]]

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

Comment 15

[Daira Hopwood]

(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.

Comment 16

[Daira Hopwood]

(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.

Comment 17

[Daira Hopwood]

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.

Comment 18

[James T. Batchelor]

This bug is still present in Thunderbird 5.0

Comment 19

[Blake Winton (:bwinton) (:☕️)]

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.

Comment 20

[Jonathan Protzenko [:protz]]

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.

Comment 21

[Jonathan Protzenko [:protz]]

Attachment: A (too?) simple fix

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 22

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 548729 [details] [diff] [review]
A (too?) simple fix

This sounds reasonable, but wants a mozmill test.

Comment 23

[Jonathan Protzenko [:protz]]

Attachment: Mozmill test to reproduce the issue

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.

Comment 24

[Jonathan Protzenko [:protz]]

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?

Comment 25

[Jonathan Protzenko [:protz]]

Attachment: The right patch checked-in 4f6a003e6273

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 26

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 549654 [details] [diff] [review]
The right patch checked-in 4f6a003e6273

(deferring review to Jim)

Comment 27

[Jim Porter (:squib)]

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 28

[Jim Porter (:squib)]

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 29

[Jonathan Protzenko [:protz]]

http://hg.mozilla.org/comm-central/rev/4f6a003e6273

Comment 30

[bitmancer.bassplayer]

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?

Comment 31

[bitmancer.bassplayer]

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.

Comment 32

[Andreas Wagner [:TheOne] [use NI]]

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?

Comment 33

[Andreas Wagner [:TheOne] [use NI]]

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

Comment 34

[bitmancer.bassplayer]

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

Comment 35

[James T. Batchelor]

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

Comment 36

[Andreas Wagner [:TheOne] [use NI]]

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.

Comment 37

[William Babb]

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

Comment 38

[bitmancer.bassplayer]

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

Comment 39

[Mathias Homann]

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.

Comment 40

[Paul Littlefield]

This is still a thing.

If you're in the folder then pressing the 'n' key works to show each next unread message, but when it has finished in that folder it will ask you "Advance to next unread message in X?" and when you press "Yes" it doesn't do it.

Comment 41

[Wayne Mery (:wsmwk)]

bug 1743119 is filed to handle the remaining work