> it should iterate from 0 to gDBView.numMsgInView and for each return gDBView.getMsgHdrAt(in nsMsgViewIndex aIndex); This solution includes threaded, invisible messages This is not doing what you described. If there are 4 messages in the view, but one is collapsed in a thread, the following happens: * `gTabmail.currentAbout3Pane.gDBView.numMsgInView` is 4 * `gTabmail.currentAbout3Pane.gDBView.rowCount` is 3 * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(0)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(1)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(2)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(3)` fails, because `getMsgHdrAt()` works on actual indices of listed messages If the thread is un-collapsed, `rowCount` is 4 and `getMsgHdrA(3)` returns a message. The correct loop-counterpart for `getMsgHdrAt()` is `rowCount`, and both ignore messages collapsed in threads. > This function returns the selected messages, not the displayed messages (tested in 115). The messageDisplay API works with the actual message display, not with the threadPane. However, the messages which are "displayed" in the mail3pane window in the message browser *are* the messages which are selected in the threadpane. The mailTabs API works with the threadpane, mailTabs.getListedMessages() returns the messages which are listed in the threadpane. There is a regression when it comes to collapsed threads. In 115 the mailTabs API included in getListedMessages() and getSelectedMessages() messages of collapsed threads. This is no longer the case in 128. This is covered in Bug 1918885. As it stands, I will make getSelectedMessages() always return the collapsed messages, and getListedMessages will receive an option to include collapsed messages or not. I will close this bug, but if you think I miss-understood something, do not hesitate to ping back.
Bug 1911480 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
> it should iterate from 0 to gDBView.numMsgInView and for each return gDBView.getMsgHdrAt(in nsMsgViewIndex aIndex); This solution includes threaded, invisible messages This is not doing what you described in Thunderbird 128. If there are 4 messages in the view, but one is collapsed in a thread, the following happens: * `gTabmail.currentAbout3Pane.gDBView.numMsgInView` is 4 * `gTabmail.currentAbout3Pane.gDBView.rowCount` is 3 * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(0)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(1)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(2)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(3)` fails, because `getMsgHdrAt()` works on actual indices of listed messages If the thread is un-collapsed, `rowCount` is 4 and `getMsgHdrA(3)` returns a message. The correct loop-counterpart for `getMsgHdrAt()` is `rowCount`, and both ignore messages collapsed in threads. > This function returns the selected messages, not the displayed messages (tested in 115). The messageDisplay API works with the actual message display, not with the threadPane. However, the messages which are "displayed" in the mail3pane window in the message browser *are* the messages which are selected in the threadpane. The mailTabs API works with the threadpane, mailTabs.getListedMessages() returns the messages which are listed in the threadpane. There is a regression when it comes to collapsed threads. In 115 the mailTabs API included in getListedMessages() and getSelectedMessages() messages of collapsed threads. This is no longer the case in 128. This is covered in Bug 1918885. As it stands, I will make getSelectedMessages() always return the collapsed messages, and getListedMessages will receive an option to include collapsed messages or not. I will close this bug, but if you think I miss-understood something, do not hesitate to ping back.
> it should iterate from 0 to gDBView.numMsgInView and for each return gDBView.getMsgHdrAt(in nsMsgViewIndex aIndex); This solution includes threaded, invisible messages This is not doing what you described in Thunderbird 128. If there are 4 messages in the view, but one is collapsed in a thread, the following happens: * `gTabmail.currentAbout3Pane.gDBView.numMsgInView` is 4 * `gTabmail.currentAbout3Pane.gDBView.rowCount` is 3 * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(0)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(1)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(2)` returns a message * `gTabmail.currentAbout3Pane.gDBView.getMsgHdrA(3)` fails, because `getMsgHdrAt()` works on actual indices of listed messages If the thread is un-collapsed, `rowCount` is 4 and `getMsgHdrA(3)` returns a message. The correct loop-counterpart for `getMsgHdrAt()` is `rowCount`, and both ignore messages collapsed in threads. > This function returns the selected messages, not the displayed messages (tested in 115). The messageDisplay API works with the actual message display, not with the threadPane. However, the messages which are "displayed" in the mail3pane window in the message browser *are* the messages which are selected in the threadpane. The mailTabs API works with the threadpane, mailTabs.getListedMessages() returns the messages which are listed in the threadpane. There is a regression when it comes to collapsed threads. In 115 the mailTabs API included in getSelectedMessages() messages of collapsed threads. This is no longer the case in 128. This is covered in Bug 1918885. As it stands, I will make getSelectedMessages() always return the collapsed messages. The new funtion getListedMessages will receive an option to include collapsed messages or not. I will close this bug, but if you think I miss-understood something, do not hesitate to ping back.