Closed Bug 1046207 Opened 10 years ago Closed 8 years ago

Compose Message window ghost exposes contents of previous composition for a moment when starting a new message

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Version:
31 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 777732

People

(Reporter: brianwraith, Unassigned)

References

Details

(Keywords: privacy, ux-trust)

Attachments

(1 file)

test patch
1.88 KB, patch
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140716183446

Steps to reproduce:

TB 31, Win XP, Compose new message after having previously composed and sent a different message.


Actual results:

When composing a new message, the compose window briefly displays a "ghost" image of the previously composed message.  The ghost only appears for a split second, but the previous message is displayed in toto.


Expected results:

I would expect a new, blank message composition window to appear.
As we cache/recycle the compose window between composing, the previous contents could be there for a moment and then should be cleared. But this should be invisible to the user. Let's see if anybody else can reproduce this.

Meanwhile, you may try to go into Options -> advanced -> config editor, find preference mail.compose.max_recycled_windows and set it to 0.
Thanks for taking the time to reply.  I made the change indicated and the ghosts were eliminated but, now I am seeing frequent black screen flashes while actively composing messages.

Here is a message id from the Mozilla forum where the author is confirming the ghost issue.

Message-ID: <sb6dnW9gdZTszEXOnZ2dnUVZ_radnZ2d@mozilla.org>
(In reply to :aceman from comment #1)
> As we cache/recycle the compose window between composing, the previous
> contents could be there for a moment and then should be cleared. But this
> should be invisible to the user. Let's see if anybody else can reproduce
> this.

Windows 7 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0
NoGlass 0.10 theme with Trebuchet MS font at 13px (via Theme Font & Size Changer extension)

I, too, see the "ghost" compose window.
I've also seen the "ghosting" for quite some time. Much more noticable, so something has changed to make it so. Perhaps the change to toolkit autocomplete?

Can you reproduce with Thunderbird in safe mode??
https://support.mozilla.org/en-US/kb/safe-mode
Flags: needinfo?(david)
Flags: needinfo?(brianwraith)
In Safe Mode, I do not see the problem.  However, not in Safe Mode but with ALL extensions disabled and with the Default theme enabled, I do see the problem.  Thus, this is not a problem with an extension or a third-party theme.
Flags: needinfo?(david)
What does help | troubleshooting show under Graphics for 
Direct2D Enabled
DirectWrite Enabled
If they are enabled, try setting in tools | options | advanced | general | config editor the three settings mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=623338#c61 to false
Both Direct2D Enabled and DirectWrite Enabled show as true in Troubleshooting Information.  (WebGL Renderer shows as false.)  However, config:edit shows layers.acceleration.force-enabled, gfx.direct2d.force-enabled, and webgl.force-enabled all as "false" without me having to change them.
I have been able to eliminate the ghosts by changing "mail.compose.max_recycled_windows" to "0", as was suggested by :aceman

I am not sure of the ramifications associated with this change, but everything seems to be working properly.
Flags: needinfo?(brianwraith)
(In reply to :aceman from comment #1)
> Meanwhile, you may try to go into Options -> advanced -> config editor, find
> preference mail.compose.max_recycled_windows and set it to 0.  

This suggested workaround conflicts with the Send Filter extension, which I really want to use.  The extension requires that mail.compose.max_recycled_windows be at least 1.  When it is 0, I get an error popup on launching Thunderbird that gives me two options: disable Send Filter or set mail.compose.max_recycled_windows to 1.  For now, I have chosen the latter, which is the default value.  

Since this is merely a minor annoyance with no real "loss of functionality" (as cited in the definition of Normal severity), I am changing this to Minor severity.
Severity: normal → minor
(In reply to :aceman from comment #1)
> As we cache/recycle the compose window between composing, the previous
> contents could be there for a moment and then should be cleared. But this
> should be invisible to the user. Let's see if anybody else can reproduce
> this.

Aceman, if we can clear the cached contents before composing a new message, can't we clear them when user sends/closes the composition window? We can still keep the entire window cached, but some of the sensitive contents like recipients, body, and attachments should be cleared so they can't reoccur even for a split second.

This can actually be a privacy issue e.g. in business environments.
Confirming per Wayne's comment 4.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(acelists)
Keywords: privacy
Summary: Compose Message window ghost → Compose Message window ghost exposes contents of previous composition for a moment when starting a new message
For what it's worth I've been experiencing this very irritating problem in TB31.0 on Win7 64. For me the old contents of the compose window are visible for several seconds before the window clears.

The setting of mail.compose.max_recycled_windows to 0 seems to have sorted it out, though I've no idea what other issues may or may not be caused by that change.
I have the same problem since I updated to Thunderbird 31. It's pretty annoying, it makes Thunderbird look like "approximately done" software (at least to people who never programmed a GUI). And more importantly, it is a privacy issue: imagine clicking "new message" with somebody near you, and Thunderbird briefly displaying some sensitive information (names of clients, financial data, personal stuff... can be anything) --- in my opinion, the cached window must be immediately cleared of its contents when it closes.
(In reply to Ale from comment #13)

Ale, thanks for pointing out that the privacy issue coming with this bug is something of concern.
Definitely not minor.

> I have the same problem since I updated to Thunderbird 31. It's pretty
> annoying, it makes Thunderbird look like "approximately done" software (at
> least to people who never programmed a GUI).

Well said ;)

> And more importantly, it is a
> privacy issue: imagine clicking "new message" with somebody near you, and
> Thunderbird briefly displaying some sensitive information (names of clients,
> financial data, personal stuff... can be anything) --- in my opinion, the
> cached window must be immediately cleared of its contents when it closes.

Yes, exactly that. I've asked aceman in comment 11 to see if we can do that.
Severity: minor → normal
In addition to briefly displaying the cached window contents when creating a new message, I just noticed that the text search field and its contents remain visible in the cached window. Not briefly: they stay there during the message composition, so you don't even need to be quick to read if you want to see what was being looked for previously. Very annoying for privacy.
Upon re-use of cached composer window, restore of window pointer is done, and ShowCachedComposeWindow() is called first before job like nsMsgComposeService::InitCompose is executed.
"Associated OS level window for composer" is perhaps enabled again by it, and it's perhaps changed to visible again at DeskTop.
If OS works pretty fast and efficiently, re-cylcled composer window can be shown to user before OnReopen event handler calls  nsMsgComposeService::InitCompose.
This kind of issue?
If so, "delayed or postponed baseWindow->SetVisibility(aShow) if aShow==true" can be a solution.

> http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp#211
>  211 nsMsgComposeService::OpenComposeWindowWithParams(const char *chrome,
>  212                                                  nsIMsgComposeParams *params)
>  
> 246       for (i = 0; i < mMaxRecycledWindows; i ++)
> 247       {
> 248         if (mCachedWindows[i].window && (mCachedWindows[i].htmlCompose == composeHTML) && mCachedWindows[i].listener)
> 249         {
> 250           /* We need to save the window pointer as OnReopen will call nsMsgComposeService::InitCompose which will
> 251              clear the cache entry if everything goes well
> 252           */
> 253           nsCOMPtr<nsIDOMWindow> domWindow(mCachedWindows[i].window);
> 254           nsCOMPtr<nsIXULWindow> xulWindow(mCachedWindows[i].xulWindow);
> 255           rv = ShowCachedComposeWindow(domWindow, xulWindow, true);
> 256           if (NS_SUCCEEDED(rv))
> 257           {
> 258             mCachedWindows[i].listener->OnReopen(params);
> 259             return NS_OK;

> http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp#1256
> 1256 nsresult nsMsgComposeService::ShowCachedComposeWindow(nsIDOMWindow *aComposeWindow, nsIXULWindow *aXULWindow, bool aShow)
>  
> 1306     // hide (show) the cached window
> 1307     rv = baseWindow->SetVisibility(aShow);
(In reply to WADA from comment #17)
> If so, "delayed or postponed baseWindow->SetVisibility(aShow) if
> aShow==true" can be a solution.
> 
> > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp#211
> >  211 nsMsgComposeService::OpenComposeWindowWithParams(const char *chrome,
> >  212                                                  nsIMsgComposeParams *params)
> >  
> > 246       for (i = 0; i < mMaxRecycledWindows; i ++)
> > 247       {
> > 248         if (mCachedWindows[i].window && (mCachedWindows[i].htmlCompose == composeHTML) && mCachedWindows[i].listener)
> > 249         {
> > 250           /* We need to save the window pointer as OnReopen will call nsMsgComposeService::InitCompose which will
> > 251              clear the cache entry if everything goes well
> > 252           */
> > 253           nsCOMPtr<nsIDOMWindow> domWindow(mCachedWindows[i].window);
> > 254           nsCOMPtr<nsIXULWindow> xulWindow(mCachedWindows[i].xulWindow);
> > 255           rv = ShowCachedComposeWindow(domWindow, xulWindow, true);
> > 256           if (NS_SUCCEEDED(rv))
> > 257           {
> > 258             mCachedWindows[i].listener->OnReopen(params);
> > 259             return NS_OK;
> 
> > http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgComposeService.cpp#1256
> > 1256 nsresult nsMsgComposeService::ShowCachedComposeWindow(nsIDOMWindow *aComposeWindow, nsIXULWindow *aXULWindow, bool aShow)
> >  
> > 1306     // hide (show) the cached window
> > 1307     rv = baseWindow->SetVisibility(aShow);

Yes, great analysis!

We could try to split ShowCachedComposeWindow (into 2 functions) such that SetVisibility(aShow) is called after the "mCachedWindows[i].listener->OnReopen(params)" line (which seems to call the JS code that initializes the window contents).

I can't personally test if that works (as I do not see the bug). Anybody up for testing?
Flags: needinfo?(acelists)
FYI.
"Am I recycledWindow?" can be known by window.gMsgCompose.recycledWindow==true/false at composer window.
(In reply to :aceman from comment #18)
> I can't personally test if that works (as I do not see the bug). Anybody up for testing?

I believe that "regression occurs or not in normal case" is far important than "it surely resolves rare, timing-dependent case of this bug". 
If no problem with not-so-quick OS on not-so-fast CPU, I thinlk we can ship fix because code change is not so big.(several liner patch?)
:aceman, "accessing BaseWindow.visibility from JavaScript" is impossible?
> http://mxr.mozilla.org/comm-central/source/mozilla/embedding/browser/nsIWebBrowser.idl#16
> http://mxr.mozilla.org/comm-central/source/mozilla/embedding/browser/nsIWebBrowser.idl#72
>    Via document, content window, DOM Window, XUL window etc., it seems that BaseWindow is accessble.
> http://mxr.mozilla.org/comm-central/source/mozilla/widget/nsIBaseWindow.idl#167
>    Via nsIBaseWindow, BaseWindow.visibility can be accessed.
Maybe, but is it fast enough? If the window is shown (from C code), and we hide it again as the first command in OnReopen() in JS, there is still a small time window when the old contents can be seen.
It seems not so easy here. Even if I do not call the SetVisibility(true), the window is still shown (at least on linux). If I call SetVisibility(false), TB crashes.
If so, change like next may be a practical solituon.
   cleanup composer window before saving the window to recycle window storehouse.
It's wasting of resouces if cahed window is not recycled(discarded), but it's better than showing garbage, and it's performance gain in re-open of cached window..
FYI.
Bug 413240 may be a friend of this bug.
   1. baseWindow->SetVisibility(false);
   2. save window in recycle window storehouse
   3. remove window from Window Enumerator
   Before SetVisibility(false) is passed to OS and is processed by OS, 3 became effective.
   Because chrome window/dom window is not accessible any more by 3,
   job of "passing Visibility=false to OS" wont't be executed, and no one can process "event at still shown window".
"Clean up between 2 and 3" may be a solution of this kind of problem, because "Clenup" takes a while.
An idea about "Cleanup just before caching composer window".
   Garbage is rendered data at end of last mail composition, or rendering result of XUL elements upon XUL window re-display.
   So, minimum clean up(clearing Subject field, message body data etc. only) may be sufficient.
   1. In XUL element definition of composer window, define Subject field etc. with class="Composer_CleanUpNeeded".
   2. Upon caching for recycle, 
   2-1 To:/CC: etc., Attachment Box
            var obj=getElementsByClassName("Composer_CleanUpNeeded") ;
            for(var xx=0;xx<obj.length;xx++){ obj[xx].innerHTML=""; }
   2-2. Message body
           vbox id=appcontent
               editor id=content-iframe
                   #document (no id => add id=appcontent-document)
                        HTML
                            HEAD
                            BODY
      =>  getElementById("appcontent-document",innerHTML="<HTML><HEAD></HEAD><BODY></BODY></HTML>" ;
      Note: If Text mode, <meta http-equiv="content-type" content="text/html; charset=utf-8"> is seen in HEAD.
   2-3. window.gMsgCompose.compFields = {}
           JavaScript error occurs upon Reopen of cached window?
           JavaScript error occurs in close event listners?
FYI.

(In reply to David E. Ross from comment #10)
> This suggested workaround conflicts with the Send Filter extension, which I really want to use. 
> The extension requires that mail.compose.max_recycled_windows be at least 1.

This is fault in addon. This is due to bad design/implementation of addon which never takes account of that mail.compose.max_recycled_windows = 0 can be used in Tb.
Does the addon work in next case?
   mail.compose.max_recycled_windows = 1
   Open two composer windows with same composition mode.
   at composer#1 : Send -> Composer window is cached for recycle, so addon works.
   at composer#2 : Send -> Composer window is physically closed because one composer window is already cached.

Above issue in composer#2 was found by Bug 814651, because mail.compose.max_recycled_windows=1 was ignored(Tb worked as if 0 always) in several Tb releases.
    Upon end of composition, addon requests setTimeout. 
    However, all of XUL Window, DOM Window, baseWindow is physically closed.
    So, setTimeout request disappears, then, mismatch between "Tb's spec" and "expectation of addon developer" occurs.
If ddon want to do "Post composition task for a composer window" after Composer Window Close event, addon should do it under single not-physically-closed-yet messenger window, instead of composer window, because "physical composer window close" can occur, even when positive number is set in mail.compose.max_recycled_windows. i.e. "composer window <-> messenger window communication by addon" is needed.
Or, addon should complete "After Send task" before Composer Window Close event occurs.
Attached patch test patch — — Splinter Review 
(In reply to WADA from comment #25)
> If so, change like next may be a practical solituon.
>    cleanup composer window before saving the window to recycle window
> storehouse.
> It's wasting of resouces if cahed window is not recycled(discarded), but
> it's better than showing garbage, and it's performance gain in re-open of
> cached window..

There is on onClose function in MsgComposeCommands.js that should clear the window contents before close. However we call that one after caching the window (http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#1420).

So I move the call to sooner before the attempt to cache it. But this is a blind attempt as I can't reproduce/test the bug. Can anybody try the patch?
:aceman, I'd be happy to test the patch, but am not used at all to dev builds of Thunderbird. Shall it be built or is there a nightly build with the patch?
Aryx, could you please push this to try so we get some builds?
Flags: needinfo?(archaeopteryx)
Pushed to Try as https://tbpl.mozilla.org/?tree=Thunderbird-Try&showall=1&rev=150a7d6d9d9c
Imported 3 patches Hiro used to get the builds going and Mozmill green.
Flags: needinfo?(archaeopteryx)
(In reply to :aceman from comment #29)
> There is on onClose function in MsgComposeCommands.js that should clear the window contents before close.
> However we call that one after caching the window
> (http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgCompose.cpp#1420).
> So I move the call to sooner before the attempt to cache it.

If it'll resolve problem, problem was:
   Because "onClose function which is invoked via mRecyclingListener->OnClose()" was kicked
   after stopping window and removing the cached Window from Window Enumerator by composeService->CacheWindow(),
   (a) no one can do "onClose function which clears window content after window close".,
   (b) or gComposeRecyclingListener["onClose"] can't clear window content.
And, it's perhaps pretty old problem...
This maybe was a cause of memory leak and required garbage collector call...
(In reply to Archaeopteryx [:aryx] from comment #32)
> Pushed to Try as
> https://tbpl.mozilla.org/?tree=Thunderbird-Try&showall=1&rev=150a7d6d9d9c
Looks like something failed in the Windows build (I'd need that one to test, as I observed the problem on Windows), apparently the import of a patch not related to this bug (see log: https://tbpl.mozilla.org/php/getParsedLog.php?id=53820828&tree=Thunderbird-Try).
Pushed again to Try, Windows + OS X builds passed, Linux failed due a different push: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=3bbd3f718e0b

Ale, can you please test a build from this push? Click on the green B and then on the "go to build directory" in the bottom left.
Flags: needinfo?(servizio.antifumo)
Just tried it (for info: the test was done on Windows 7 x64, on an average speed laptop with a dual-core i7, on battery, "balanced" power policy).

It looks better than before, although I'd say it is not perfect: the window contents are still cleared when the window opens, and they are visible for a very very short time (not enough to read whatsoever from the window). Then it becomes completely white for a small fraction of a second (I'd say the same time it was displaying the old message before), then becomes usable (similar to what is mentioned in comment #22, although the window is white and not hidden). So while the patch seems to at least mostly solve the privacy problem, it is relatively bad looking from a pure UX perspective (but it is better than nothing...). So it seem that the window is not actually cleaned before caching.
Flags: needinfo?(servizio.antifumo)
So we still don't know what changed in or prior to version 31 that causes this change in behavior?
IIRC using windows recycling was broken for the whole 24 period...
Violating user privacy certainly undermines ux-trust.
Keywords: ux-trust
(In reply to Thomas D. from comment #39)
> Violating user privacy certainly undermines ux-trust.

I agree, also seeing this bug quite unexpectedly in TB31.  This is exactly the kind of bug behind why I don't like to "upgrade" because doing so can introduce bugs with new and negative results.

I also highly value Send Filters.  As a power user of filters and folders, I regard this as core functionality; disabling it is not an attractive workaround.  

Can we move the steps that clear out all message-specific data to just after the Compose window gets closed (e.g. message sent)?  Not keeping that in memory might also help reduce TB's memory load.
Linking in a discussion from 2012 (this issue still persists!): http://mozilla.6506.n7.nabble.com/Should-we-stop-recycling-the-compose-window-td172929.html
The "moment" in the bug summary can be a full minute or more depending how slow the computer is running.  This is not great for privacy.

Bug 814651 (from 2012) seems to be related, especially to why Send Filters doesn't work when turning off window recycling.  Its keywords are "qawanted, regression, reproducible." 

In https://bugzilla.mozilla.org/show_bug.cgi?id=814651#c19 Aceman wrote:
> I think the intention is to remove caching of the compose window 
> (there is a bug for it) so maybe nobody should rely on it in new code.
Bug 777732 "Remove vestiges of compose window recycling" has also been open since 2012, and appears to be what he's is referring to.  That might be a decent long-term solution, but if even shorter term solutions that remove the re-display of the last message can be applied, that would fix this bug.
Here's a rough sketch for a fix.
When opening a compose window, there is some code (a function or lines of code that could be made into a function) which clears out the contents of the window (e.g. recipients, subject line, message body, maybe resetting message options, etc.) from when it was last used.  Sometimes, it takes a short while for this code to run and/or complete, causing this bug.  For the purpose of this sketch & without knowledge of the relevant part of the code base, I'll call that functionality clearContents().  Right now, that's run *after opening a Compose window* at least when that window is recycled.  

My rough sketch proposal is to move that call to a point that is very late in the "close window" sequence, after plugin calls and after any code that relies on having the contents of the message there.  Then we'd be doing the clear-out at what might be considered a "less valuable time" (i.e. it might make the window close process a little slower) but it could speed up the Message Compose Window startup process, while also solving the ux-trust and privacy issues currently presented.  

This means the clearContents() code is run one time per session more than strictly needed (after closing the last compose window), but people are more likely to be waiting on the compose window to start up than they are to be waiting on it to completely close, and I think the user trust & privacy issues are more important.

As an edge case to consider, are there cases where the window-closing process might be interrupted before the clearing, but the window still made available for recycling? If so, we may want to keep (another copy of?) that call where it is now, perhaps wrapped in a check to see if it was already done successfully (bit set just after clearContents() in the previous close).  

What do you think?
I think that I will remove the recycling in bug 777732 soon.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
(In reply to Jorg K (GMT+1) from comment #44)
> I think that I will remove the recycling in bug 777732 soon.

Thanks for the intention of working on this!  
However, I think it shouldn't quite be marked as Resolved until it is resolved ("soon" can mean years around here), and it is separate from bug 777732 in that there are possibly other ways to fix it (e.g. see Comment 43).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I would appreciate if you could respect my decision to resolve this as a duplicate.
Resolved as a duplicate doesn't actually mean that the problem is resolved, it means that the duplicate isn't given any attention, as it will be automatically resolved, when the other bug gets resolved.

I *will* work on this this year. It won't be in TB 45, but it will be in TB 52. Thunderbird only does ESR releases, however, it will be in a beta release earlier.

We don't need to consider other solutions (which also wouldn't be available earlier) since we are determined to remove the root cause of the problem. If you read bug 777732, you will see that the three chief developers, Kent, Joshua and Magnus, had agreed to the removal.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → DUPLICATE
(In reply to WBT from comment #42)
> The "moment" in the bug summary can be a full minute or more depending how
> slow the computer is running.  This is not great for privacy.

Have you actually observed a computer where this takes a minute? What kind of computer is it?
If you're concerned about privacy, you can switch the recycling off now.
Just go to Tools > Options, Advanced tab, Config editor. Look for mail.compose.max_recycled_windows and set this to zero. That's the end of all your problems, no need to wait for years as you said in comment #46.
(In reply to Jorg K (GMT+1) from comment #47)
> If you read bug 777732, you will see that the three chief developers, Kent,
> Joshua and Magnus, had agreed to the removal.
Yes, but consensus to remove window recycling goes back to 2012.  See http://mozilla.6506.n7.nabble.com/Should-we-stop-recycling-the-compose-window-td172929.html, a thread which Joshua started, where he did performance tests etc. 

(In reply to :aceman from comment #48)
> Have you actually observed a computer where this takes a minute? What kind
> of computer is it?
Yes, an Acer Aspire E15 with 4GB RAM, 2.16 GHz 64-bit processor, Win10. 

(In reply to Jorg K (GMT+1) from comment #49)
> If you're concerned about privacy, you can switch the recycling off now.
> Just go to Tools > Options, Advanced tab, Config editor. Look for
> mail.compose.max_recycled_windows and set this to zero. That's the end of
> all your problems, no need to wait for years as you said in comment #46.
That is not true, because doing that disables Send Filters, which to me is core functionality.  See Comment 10 and Comment 40 and maybe Bug 814651.  If the effect of your patch is to disable this functionality, then that would be a good argument for fixing this specific bug, as discussed in Comment 11, Comment 13, Comments 25-27, Comment 29-36, Comment 40, and Comment 43 (or the approach in Comments 17-18 which might not fully solve the issue per Comment 22).  To me, this is further support for keeping this bug open independently of bug 777732.
> (In reply to :aceman from comment #48)
> > Have you actually observed a computer where this takes a minute? What kind
> > of computer is it?
> Yes, an Acer Aspire E15 with 4GB RAM, 2.16 GHz 64-bit processor, Win10. 
If it matters, the processor is also quad-core and labeled as "up to 2.58 GHz."  The RAM is DDR3 L.
(In reply to WBT from comment #51)
> > (In reply to :aceman from comment #48)
> > > Have you actually observed a computer where this takes a minute? What kind
> > > of computer is it?
> > Yes, an Acer Aspire E15 with 4GB RAM, 2.16 GHz 64-bit processor, Win10. 
> If it matters, the processor is also quad-core and labeled as "up to 2.58
> GHz."  The RAM is DDR3 L.

Thanks for the specs. That seems to be a recent computer which should be supported and should run TB just fine. I'd expect opening a compose window should take a split of a second on it, with recycling or not. This taking up to a minute is totally pathological behaviour that should be investigated. I'd recommend opening a new bug with such a report as we do not want opening compose window to take so long. Fixing the bug here (removing recycling) will only make the opening even longer (albeit the consensus is that not by much) so will not fix the new bug.
(In reply to :aceman from comment #52)
> a minute is totally pathological behaviour that should be investigated.
> I'd recommend opening a new bug with such a report 

Also, please make it blocking bug 777732. Thanks.
Status: RESOLVED → VERIFIED
(In reply to :aceman from comment #52)
> This taking up
> to a minute is totally pathological behaviour that should be investigated.
> I'd recommend opening a new bug with such a report as we do not want opening
> compose window to take so long. 

I'm not sure how to go about the investigation...the computer seems to perform slowly overall, and other tasks in Thunderbird (e.g. opening a simple message) also take much longer on this machine than on a much better-spec'ed one I previously used.  If I could identify the cause of the issue as being something in the TB codebase, I'd open another bug as requested, but I don't think the information I have now would be sufficiently / actionably useful.  

>Removing recycling will only make the opening even longer 
>(albeit the consensus is that not by
> much) so will not fix the new bug.

I'm not sure "removing recycling will only make the opening even longer." Joshua's tests in 2012 (http://mozilla.6506.n7.nabble.com/Should-we-stop-recycling-the-compose-window-tp172929p172938.html) counter-intuitively indicated it can actually make opening *faster,* but Aceman's much more recent tests (Bug 777732 Comment 13) indicate a slight performance hit.  
However, IF removing recycling does increase Compose window opening time, then it's a good point that fixing Bug 777732 would hurt the performance bug.  This is another argument for fixing this (bug 1046207) on its own, e.g. by clearing contents at the end of a compose process instead of at the beginning, or at least considering it on its own instead of duping it.
(In reply to WBT from comment #54)
> (In reply to :aceman from comment #52)
> > This taking up
> > to a minute is totally pathological behaviour that should be investigated.
> > I'd recommend opening a new bug with such a report as we do not want opening
> > compose window to take so long. 
> 
> I'm not sure how to go about the investigation...the computer seems to
> perform slowly overall, and other tasks in Thunderbird (e.g. opening a
> simple message) also take much longer on this machine than on a much
> better-spec'ed one I previously used.  If I could identify the cause of the
> issue as being something in the TB codebase, I'd open another bug as
> requested, but I don't think the information I have now would be
> sufficiently / actionably useful.  

Obviously it's premature to say whether it's actionable. But we're not asking you to completely debug it.  You're choice to file a bug or not. 

> >Removing recycling will only make the opening even longer 
> >(albeit the consensus is that not by
> > much) so will not fix the new bug.
> 
> I'm not sure "removing recycling will only make the opening even longer."
> Joshua's tests in 2012
> (http://mozilla.6506.n7.nabble.com/Should-we-stop-recycling-the-compose-
> window-tp172929p172938.html) counter-intuitively indicated it can actually
> make opening *faster,* but Aceman's much more recent tests (Bug 777732
> Comment 13) indicate a slight performance hit.  

Joshua is one data point, so it's not gospel.


> it's a good point that fixing Bug 777732 would hurt the performance
> bug.  This is another argument for fixing this (bug 1046207) on its own,
> e.g. by clearing contents at the end of a compose process instead of at the
> beginning, or at least considering it on its own instead of duping it.

As already stated, development is clearly not going in the direction of fixing *this* bug. N.B. the "Verified" status of this bug's resolution.
(In reply to WBT from comment #50)
> (In reply to Jorg K (GMT+1) from comment #49)
> > If you're concerned about privacy, you can switch the recycling off now.
> > Just go to Tools > Options, Advanced tab, Config editor. Look for
> > mail.compose.max_recycled_windows and set this to zero. That's the end of
> > all your problems, no need to wait for years as you said in comment #46.
> That is not true, because doing that disables Send Filters, which to me is
> core functionality.  See Comment 10 and Comment 40 and maybe Bug 814651.  If
> the effect of your patch is to disable this functionality, then that would
> be a good argument for fixing this specific bug, as discussed in Comment 11,
> Comment 13, Comments 25-27, Comment 29-36, Comment 40, and Comment 43 (or
> the approach in Comments 17-18 which might not fully solve the issue per
> Comment 22).  To me, this is further support for keeping this bug open
> independently of bug 777732.
Thanks for the hint. I will keep an eye out for sent filters when working on bug 777732.
Oops, you're talking about a "send filter" add-on?
https://addons.mozilla.org/en-US/thunderbird/addon/send-filter/
Well, we will remove windows recycling and the add-on author will have to adapt to that. Besides, why does it need an add-on? Since TB 38 there are "Send Filters" as part of the product. Do they not work or are they not sufficient?
(In reply to Jorg K (GMT+1) from comment #57)
> Oops, you're talking about a "send filter" add-on?
> https://addons.mozilla.org/en-US/thunderbird/addon/send-filter/

Yes, the extension was mentioned in this bug. But you need to check whether rkent's built-in version of send filters depends on recycling.

> Well, we will remove windows recycling and the add-on author will have to
> adapt to that. Besides, why does it need an add-on? Since TB 38 there are
> "Send Filters" as part of the product. Do they not work or are they not
> sufficient?

That is a good question. The addon is still updated even for TB38. I don't know if it has any use, better would be to ask the author.
(In reply to Jorg K (GMT+1) from comment #57)
> Oops, you're talking about a "send filter" add-on?
> https://addons.mozilla.org/en-US/thunderbird/addon/send-filter/
> Well, we will remove windows recycling and the add-on author will have to
> adapt to that. Besides, why does it need an add-on? Since TB 38 there are
> "Send Filters" as part of the product. Do they not work or are they not
> sufficient?

The Send Filter extension for Thunderbird was rendered obsolete by the implementation of its functionality into "vanilla" Thunderbird.  I was using that extension but removed it about a year ago.  See bug #11039.  Thus, it is important that correcting this bug or bug #777732 not adversely impact the inherent "send filter" capability.
(In reply to Jorg K (GMT+1) from comment #57)
> Besides, why does it need an add-on? Since TB 38 there are
> "Send Filters" as part of the product. Do they not work or are they not sufficient?

Though I am glad this got integrated in with "vanilla" Thunderbird, the built-in feature does not work by default.  It seems that to make it work, I have to manually go through each of hundreds of filters and enable each one's "after sending" box individually.  However, while the add-on exists, a bug filed about this would most likely be met with something like "just use the add-on," "suck it up and go through it all manually," or "write your own addon to do it faster," "this is not a problem for TB," or more optimistically, "maybe put this on the list to fix years down the road."   

(In reply to Jorg K (GMT+1) from comment #57)
> Well, we will remove windows recycling and the add-on author will have to
> adapt to that. 
(Implied: And if the add-on author doesn't, users will just lose that functionality without warning, as a penalty for updating their software.) 

I really dislike this philosophy and more than anything else, that's what's led me to not be a more active member of this community.  I've been asking for a change in that since at least Bug 670302, to let users make an informed choice about updating their software knowing the loss/gain in functionality that may result, and the problem has only gotten worse.  Mozilla used to represent values of informed choice and user control, but that's eroded quite a bit, usually in the name of "security."  The semi-recent transition to requiring add-on signing was just another strong example.  

If the add-on will be disabled by removing window recycling, it would be nice to at the very least inform users as part of the update process *before* they click the update button which will remove that functionality, and ideally make the transition to comparable functionality as seamless as possible.
<off topic>
A lot of things could be said here. The facts are that currently the TB development is unfunded and based on unpaid volunteers alone. Sadly, if you want something implemented, you need to implement it yourself (that's how I started one year ago) or write an add-on that again you need to maintain yourself. This situation will hopefully change in the future when TB has found a new financial home and can receive and spend money.
Sadly we have no manpower whatsoever for looking into add-ons and update issues. Responsible add-on authors will always keep their add-ons up-to-date and release new versions as required since it is their software. Talking about a penalty is not fair. You can chose to use TB 1.5 and the add-ons that go with it. If you want new functionality, the risk is that badly maintained add-ons might stop working.
</off topic>.

Switching rules on in bulk is simple. Edit the msgFilterRules.dat file with a text editor.

Manually run: type="16"
Getting new mail, before junk: type="1"
Getting new mail, after  junk: type="32"
Archiving: type="128"
After sending: type="64"
Details: https://dxr.mozilla.org/comm-central/source/mailnews/base/search/public/nsMsgFilterCore.idl#12

If you want to add "after sending", add 64 to all existing values.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: