Bug 2008314 Comment 6 Edit History

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

That is rather strange. I retested it and it works fine here. You noticed that I updated the patch:
```C++
+                nsCOMPtr<nsIThread> thread(do_GetCurrentThread());
+                while (NS_ProcessNextEvent(thread)) {
+                  // Do nothing, just process all the pending events.
+                }
```
The loop should run while there are pending events. One could add a break that somehow gets triggered when rule execution is finished from here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/nsMsgCopy.cpp#93
That's what triggers the "after send" rule execution here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/MessageSend.sys.mjs#541
That is rather strange. I retested it and it works fine here. You noticed that I updated the patch:
```C++
+                nsCOMPtr<nsIThread> thread(do_GetCurrentThread());
+                while (NS_ProcessNextEvent(thread)) {
+                  // Do nothing, just process all the pending events.
+                }
```
The loop should run while there are pending events. One could add a break that somehow gets triggered when rule execution is finished from here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/nsMsgCopy.cpp#93
That's what triggers the "after send" rule execution here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/MessageSend.sys.mjs#541

Update: this hacky approach also works:
```
                (void)OnCopyCompleted(m_copyState->m_srcSupport, aExitCode);
                // Clear event queue, that is, execute "after send" filters,
                // before calling `UpdateFolderWithListener()`.
                nsCOMPtr<nsIThread> thread(do_GetCurrentThread());
                PRTime startTime = PR_Now();
                while (NS_ProcessNextEvent(thread) && PR_Now() - startTime < 1000000) {
                  // Do nothing, just process all the pending events.
                }
                UpdateFolderWithListener(msgWindow, m_urlListener);

```
I'll see whether I can implement something that waits for the rule execution to finish before calling `UpdateFolderWithListener()`.
That is rather strange. I retested it and it works fine here. You noticed that I updated the patch:
```C++
+                nsCOMPtr<nsIThread> thread(do_GetCurrentThread());
+                while (NS_ProcessNextEvent(thread)) {
+                  // Do nothing, just process all the pending events.
+                }
```
The loop should run while there are pending events. One could add a break that somehow gets triggered when rule execution is finished from here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/nsMsgCopy.cpp#93
That's what triggers the "after send" rule execution here:
https://searchfox.org/comm-central/rev/c6d3230444583664b4ef87a8466a99634f5a6284/mailnews/compose/src/MessageSend.sys.mjs#541

Update: this hacky approach also works:
```
                (void)OnCopyCompleted(m_copyState->m_srcSupport, aExitCode);
                // Clear event queue, that is, execute "after send" filters,
                // before calling `UpdateFolderWithListener()`.
                nsCOMPtr<nsIThread> thread(do_GetCurrentThread());
                PRTime startTime = PR_Now();
                while (NS_ProcessNextEvent(thread) && PR_Now() - startTime < 1000000) {
                  // Do nothing, just process all the pending events.
                }
                UpdateFolderWithListener(msgWindow, m_urlListener);

```
I'll see whether I can implement something that waits for the rule execution to finish before calling `UpdateFolderWithListener()`.

Update 2: In Phab use of `NS_ProcessPendingEvents(thread);` was suggested. I'll try this later, thanks Hartmut!

Back to Bug 2008314 Comment 6