Bug 341266 Comment 41 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Ben Merritt from comment #40)
> I'm still making the occasional effort to move this forward. It looks like something (specifics still unknown) in a JavaScript event handler is causing a call to `nsMsgDBFolder::SetMsgDatabase(nullptr)`, which drops the event handlers that are listening to changes in the folder's read status. The event listeners are eventually reinstated, but by then, the test has already moved on.

When a folder is selected, the database for the previously shown folder generally is [closed](https://searchfox.org/comm-central/rev/c9aac85e9665c76ec37abda594a3826e1dd090da/mail/modules/DBViewWrapper.sys.mjs#693), so marking the message header read doesn't notify about a change in the folder. Instead use the `markAllMessagesRead` or `markMessagesRead` for the folder.

Some more hints: [D248684](https://phabricator.services.mozilla.com/D248684) needs to be rebased, and while you are at it, I'd really recommend combining all four patches into one (using `histedit fold`). If there are only some minor issues you are stuck with, but the patch is generally working, it's mostly better to just request review, otherwise any questions you have may not get the attention they deserve.

After all, your contribution already seems to work just fine!
(In reply to Ben Merritt from comment #40)
> I'm still making the occasional effort to move this forward. It looks like something (specifics still unknown) in a JavaScript event handler is causing a call to `nsMsgDBFolder::SetMsgDatabase(nullptr)`, which drops the event handlers that are listening to changes in the folder's read status. The event listeners are eventually reinstated, but by then, the test has already moved on.

When a folder is selected, the database for the previously shown folder generally is [closed](https://searchfox.org/comm-central/rev/c9aac85e9665c76ec37abda594a3826e1dd090da/mail/modules/DBViewWrapper.sys.mjs#693), so marking the message header read doesn't notify about a change in the folder. Instead use the `markAllMessagesRead` or `markMessagesRead` for the folder.

Some more hints: [D248684](https://phabricator.services.mozilla.com/D248684) needs to be rebased, and while you are at it, I'd really recommend combining all four patches into one (using `hg histedit -> fold`). If there are only some minor issues you are stuck with, but the patch is generally working, it's mostly better to just request review, otherwise any questions you have may not get the attention they deserve.

After all, your contribution already seems to work just fine!
(In reply to Ben Merritt from comment #40)
> I'm still making the occasional effort to move this forward. It looks like something (specifics still unknown) in a JavaScript event handler is causing a call to `nsMsgDBFolder::SetMsgDatabase(nullptr)`, which drops the event handlers that are listening to changes in the folder's read status. The event listeners are eventually reinstated, but by then, the test has already moved on.

When a folder is selected, the database for the previously shown folder generally is [closed](https://searchfox.org/comm-central/rev/c9aac85e9665c76ec37abda594a3826e1dd090da/mail/modules/DBViewWrapper.sys.mjs#693), so marking the message header read doesn't notify about a change in the folder. Instead use the `markAllMessagesRead` or `markMessagesRead` for the folder.

Some more hints: [D248684](https://phabricator.services.mozilla.com/D248684) needs to be rebased, and while you are at it, I'd really recommend combining all four patches into one (using `hg histedit` -> `fold`). If there are only some minor issues you are stuck with, but the patch is generally working, it's mostly better to just request review, otherwise any questions you have may not get the attention they deserve.

After all, your contribution already seems to work just fine!

Back to Bug 341266 Comment 41