1083994 - view message body fails in the message pane, requiring new messenger window open. (After rename of imap folder where mail is shown in messagepane, exception of "0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" occurs in ClearMessagePane)

Status: NEW

(Thunderbird :: Message Reader UI, defect)

Description

[capndave]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Build ID: 20140923194127

Steps to reproduce:

- Upgrading to v31 - including 31.2.0
- Default installation.  
- Default classic pane view.

1) Click on the Subject of any message in the message pane.
2) The message body does not appear.
3) Restart Thunderbird.
4) Click on a message subject.  The body appears.

In my case, this happens approximately 25% of the time.
It happens regardless of whether the emails are from IMAP or Local.



Actual results:

The message body does not appear.


Expected results:

The message body should have appeared.

Comment 1

[capndave]

One addendum to the repeatability of this:

While I have reproduced this after a clean startup, it seems most repeatable after using Thunderbird
for a few, to many, minutes of typical use.  Typically use, being the viewing emails from Inbox and/or
various folders. I have not seen any trigger patterns, but it's definitely a problem for my installation.

Comment 2

[Wayne Mery (:wsmwk)]

Does it happen with Thunderbird started in safe mode??  (Help | Restart)

Are the messages plain text? Or does it have attachments?

If the later doing view source will show things like 
This is a multi-part message in MIME format.
Content-Type: text/

Comment 3

[capndave]

I have more data to help isolate this.

1) Changed value of "Automatically mark messages as read" property.
   I switched the property value of "Automatically mark messages as read"
   to "Immediately on display".  It was previously set to 10 seconds.
   I did this on 4 days ago and I have not hit the reported issue at all.
   Perhaps there was a change in the "auto mark" code for v31 that needs to be revisited.

2) To address Wayne Mery's questions.  No I have not run in safemode.  The issue is
   is reproducibly whether or not an attachment is present.

Comment 4

[Wayne Mery (:wsmwk)]

see comment 3.  I hesitate to all this a regression just yet.

Comment 5

[:aceman]

Anything in Tools->Error console after the body does not display?
Have you tried repairing the folder in rightclick->Properties->Repair?

Comment 6

[capndave]

We can rule out the auto mark logic that I suggested in Comment 3.  It has been happening again a lot.

Per Comment 5, I cleared and checked the logs immediately after the problem manifests.

Timestamp: 11/7/2014 9:15:43 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 96

Timestamp: 11/7/2014 9:15:43 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 11/7/2014 9:15:43 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

...

Comment 7

[capndave]

Just to add, to Comment 6.  Once the problem manifests, it happens 100% of the time.  I.e., no matter which folder I click on, the message pane does not display the email.  The ONLY solution after
that is to restart Thunderbird.

Comment 8

[capndave]

Raising to P2, Critical, since when this occurs Thunderbird is completely unusable until restarted.
The workday is only 4 hours old and I have restarted over 20 times.

Comment 9

[capndave]

I have verified this is also an issue on RH Linux, after upgrading to Thunderbird 31.
I was using Thunderbird ESR 24.7 perfectly all week, until yum'ing to the latest 31.
Within a few minutes, the issue was hit.  Surely I cannot be the only one hitting this.

It would seem that it is time to get some engagement on this issue and flesh it out.
The error log in Comment 6 would seem to be a smoking gun, no?

Comment 10

[capndave]

Change platform to All, since this has also now been verified on Linux.

Comment 11

[capndave]

Assigned to Message Reader UI, given the logs in Comment 6.

Comment 12

[capndave]

I have reverted back to Thunderbird 24.8 and as expected, the issue is not reproducible.

I will stay on 24.8 until this issue is fixed, but this appears to be a bona-fide major regression in 31.

Comment 13

[capndave]

Still reproducible using the 31.3.0 update.

Comment 14

[capndave]

Moving to P1 since this renders Thunderbird useless.

Sorry, but this is a showstopper regression in my user experience that does NOT occur with 24.X.

See Comment 6 for error log message.  Previous comments are obsolete.

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to capndave from comment #8)
> Raising to P2, Critical, since when this occurs Thunderbird is completely
> unusable until restarted.
> The workday is only 4 hours old and I have restarted over 20 times.

please attempt to reproduce with 31.x started in safe mode.

Comment 16

[capndave]

In response to comment #15:
> please attempt to reproduce with 31.x started in safe mode.

Yes.  Issue is reproducible on 31.3.0 in safe mode.  
Error Log output is exactly the same (see comment #6).
Repeatability and impact are exactly the same (ie., dead in the water until TB restart).

Again, I appeal - why is this not getting more attention and why was it downgraded from a a blocker?
TB is rendered unusable and I reboot every couple of minutes.  Going back to 24.8 until this is fixed.

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to capndave from comment #6)
> Timestamp: 11/7/2014 9:15:43 AM
> Error: [Exception... "Component returned failure code: 0x80070057
> (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057
> (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
> chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line
> 1103"  data: no]

ClearMessagePane()
> http://mxr.mozilla.org/comm-release/source/mail/base/content/msgMail3PaneWindow.js#1105
> 1105 function ClearMessagePane()
> 1106 {
> 1107   // hide the message header view AND the message pane...
> 1108   HideMessageHeaderPane();
> 1109   gMessageNotificationBar.clearMsgNotifications();
> 1110   ClearPendingReadTimer();
> 1111   try {
> 1112     // This can fail because cloning imap URI's can fail if the username
> 1113     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> 1114     let messagePane = GetMessagePaneFrame();
> 1115     // If we don't do this check, no one else does and we do a non-trivial
> 1116     // amount of work.  So do the check.
> 1117     if (messagePane.location.href != "about:blank")
> 1118       messagePane.location.href = "about:blank";
> 1119   } catch(ex) {
> 1120       logException(ex, false, "error clearing message pane");
> 1121   }
> 1122 }

Exception happened, then process at message pane doesn't work as expected?

If timinf dependent, it may be "messagePane.location is not initialized yet"(i.e. messagePane.location is undefined)
Is "messagePane.location is always accessible" guaranteed at any step, at any timing?
Following may be solution, and tit's ordinal solution of this kind of exception upon "xx.yy.zz access when xx.yy is not available, without existence check of xx.yy".
         if (messagePane && messagePane.location && messagePane.location.href != "about:blank")
             messagePane.location.href = "about:blank";
         else if (messagePane && !messagePane.location)
             Error handling code
         else if (!messagePane )
             Error handling code

> http://hg.mozilla.org/comm-central/annotate/88bde0fc609a/mail/base/content/msgMail3PaneWindow.js#l1076
> http://hg.mozilla.org/comm-central/diff/1e333d47863d/mail/base/content/msgMail3PaneWindow.js
> http://hg.mozilla.org/comm-central/rev/1e333d47863d
> https://bugzilla.mozilla.org/show_bug.cgi?id=545955
> https://bug545955.bugzilla.mozilla.org/attachment.cgi?id=440694
This code was added by bug 545955.
It looks for me "messagePane.location.href!=about:blank occurred, so exception happened, then messagePane.location.href = "about:blank" is done by this code, and after it, exception occurred when this code saw "messagePane.location is not initialized".

It may be that Recent PC is too fast and have many Cores, and sophisticated OS runs too quickly and efficiently, so ClearPendingReadTimer() is invoked too quickly.

Comment 18

[:aceman]

The line 1103 is not inside the ClearMessagePane function today. Can you provide the error message from TB 31.3 so we can be sure about the exact line that is throwing the error?

Comment 19

[capndave]

Thanks wada, aceman.  Here are some answers.

1) Regarding about:blank in comment #17
I sometimes see a warning message entry that says (I've privatized the link):
Security Error: Content at imap://[e-mail]:993/fetch%3EUID%3E/INBOX%3E160452 may not load or link to about:blank.

2) Regarding hardware timing comments in #17
I run Win7 on a i5-3320M @ 2.6GHz with 8G Ram.
I also run RHEL 6 on E8400 @ 3.00GHz with 4G Ram.
Interestingly, I also run Virtualized RHEL 6 with 1 core, 2GB ram, and I cannot seem to reproduce.
Hmm.
 
3) Regarding aceman #18.
I will get you a 31.3 error message and post it.

Comment 20

[capndave]

> 3) Regarding aceman #18.
> I will get you a 31.3 error message and post it.

Verified the Error message "trio" (ie., Line 96, 34, 35) is the same for 31.3 and references line 1103.

Note, once the problem manifests, the "trio" shows in the log each time there is an attempt to click on a message folder.  Ie., if I click on 10 folders, there will be 30 logs entries in the Errors section.

Timestamp: 12/19/2014 11:44:07 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 96

Timestamp: 12/19/2014 11:44:07 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 12/19/2014 11:44:07 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 21

[capndave]

Note:  The error message 'trio' on 31.3.0 for my *Linux* install has different is still 96, 34, 35
but the error message references line 1079 instead of 1103.

Timestamp: 12/23/2014 10:10:47 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Source File: resource:///modules/errUtils.js
Line: 96

Timestamp: 12/23/2014 10:10:47 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 12/23/2014 10:10:47 AM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 22

[:aceman]

Yeah, that file is preprocessed and has different contents for each OS. The difference of 1103 vs. 1079 can be explained by one block   403 #ifdef XP_WIN to    427 #endif that is removed on Linux.
So with this info the line numbers seem to match:
  1091 function ClearMessagePane()
  1092 {
  1093   // hide the message header view AND the message pane...
  1094   HideMessageHeaderPane();
  1095   gMessageNotificationBar.clearMsgNotifications();
  1096   ClearPendingReadTimer();
  1097   try {
  1098     // This can fail because cloning imap URI's can fail if the username
  1099     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
  1100     let messagePane = GetMessagePaneFrame();
  1101     // If we don't do this check, no one else does and we do a non-trivial
  1102     // amount of work.  So do the check.
  1103     if (messagePane.location.href != "about:blank")
  1104       messagePane.location.href = "about:blank";
  1105   } catch(ex) {
  1106       logException(ex, false, "error clearing message pane");
  1107   }

It really looks like the location.href is failing for some reason.
But I still do not understand why the try {} catch() {} block does not hide the error and allows the code to continue.

Neil, would you have an idea why the exception is not catched? Or is it not how it is supposed to work?

Comment 23

[[e-mail]]

(In reply to capndave from comment #21)
> Error: error clearing message pane

(In reply to aceman from comment #22)
>   1105   } catch(ex) {
>   1106       logException(ex, false, "error clearing message pane");
>   1107   }

> Neil, would you have an idea why the exception is not catched? Or is it not
> how it is supposed to work?

What makes you think that the exception hasn't been caught?

Comment 24

[Wayne Mery (:wsmwk)]

> Again, I appeal - why is this not getting more attention 
because no one else is seeing it

> and why was it downgraded from a blocker?
blocker means - "blocks development work". This bug does not.

(In reply to [e-mail] from comment #23)
> (In reply to capndave from comment #21)
> > Error: error clearing message pane
> 
> (In reply to aceman from comment #22)
> >   1105   } catch(ex) {
> >   1106       logException(ex, false, "error clearing message pane");
> >   1107   }
> 
> > Neil, would you have an idea why the exception is not catched? Or is it not
> > how it is supposed to work?
> 
> What makes you think that the exception hasn't been caught?

Comment 25

[Wayne Mery (:wsmwk)]

(In reply to capndave from comment #3)
> I have more data to help isolate this.
> 
> 1) Changed value of "Automatically mark messages as read" property.
>    I switched the property value of "Automatically mark messages as read"
>    to "Immediately on display".  It was previously set to 10 seconds.
>    I did this on 4 days ago and I have not hit the reported issue at all.
>    Perhaps there was a change in the "auto mark" code for v31 that needs to
> be revisited.

not that I am aware of.

What happens for other values for seconds, like 1, or 30?

Comment 26

[:aceman]

(In reply to Wayne Mery (:wsmwk) from comment #24)
> (In reply to [e-mail] from comment #23)
> > (In reply to capndave from comment #21)
> > > Error: error clearing message pane
> > (In reply to aceman from comment #22)
> > >   1105   } catch(ex) {
> > >   1106       logException(ex, false, "error clearing message pane");
> > >   1107   }
> > > Neil, would you have an idea why the exception is not catched? Or is it not
> > > how it is supposed to work?
> > What makes you think that the exception hasn't been caught?
Yeah, so the code probably catches the exception but explicitly logs it again.
I don't know what to do here. The comment in the code indicates the situation is normal so why it breaks the view is unknown yet.

Comment 27

[capndave]

> What happens for (automatically mark as read) other values for seconds, like 1, or 30?
After further testing, the value of that parameter is irrelevant.

> because no one else is seeing it
I'm the lucky one.

HERE IS SOME FRESH DATA
***********************
I did a fresh Windows 7 installation, with a fresh TB 31.4.0 installation, with the out-of-box TB configuration.  Unfortunately, the issue reproduced readily.

Here are fresh error logs, based off 31.4.0.  
As a reminder, once the problem manifests, then each attempt to access any folder generates TWO
consecutive groups of error entries ... ie., line 96, line 34, line 35, line 96, line 34, line 35.
So, if I click on 2 folders there are 12 log entries, 6 duplicate entries.

Timestamp: 2/23/2015 3:42:03 PM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 96

Timestamp: 2/23/2015 3:42:03 PM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 2/23/2015 3:42:03 PM
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1103"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 28

[capndave]

This is also reproducible on (a new) Mac.  Clean install of Thunderbird 31.5.
Same exact errors, including line number, as on Windows, Linux.
Hit it in less than 2 hours of use after initial IMAP load and global indexing.
Beyond frustrated with this.

Comment 29

[capndave]

Modified subject of bug to be more accurate.

< Regression : v31 : view the message body in the message pane fails with "Automatically mark messages as read"

> Regression : v31 : Inability to view message body in the message pane, requiring reboot of TB.

Comment 30

[[e-mail]]

I appear to have a similar problem - at least I have the same error message being logged in the Error Console.  In my case I'm running v38 in a Fedora environment and everything is fine until I delete a folder.

It doesn't seem to matter if I use the delete key, select delete from the context menu or drag the folder to the deleted folder.

However I can recover the ability to view the message body by changing the layout using View > Layout.  It doesn't seem to make any difference which layout I choose as long as I change it.

The issue is recreatable in safe mode.

Unix logs:
Jun  1 10:11:44 wark /etc/gdm/Xsession: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Jun  1 10:11:44 wark /etc/gdm/Xsession: Exception (error clearing message pane)
Jun  1 10:11:44 wark /etc/gdm/Xsession: -- Exception object --
Jun  1 10:11:44 wark /etc/gdm/Xsession: + toString (function) 3 lines
Jun  1 10:11:44 wark /etc/gdm/Xsession: + message (string) 'Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + result (number) 2147942487
Jun  1 10:11:44 wark /etc/gdm/Xsession: + name (string) 'NS_ERROR_ILLEGAL_VALUE'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + filename (string) 'chrome://messenger/content/msgMail3PaneWindow.js'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + lineNumber (number) 1079
Jun  1 10:11:44 wark /etc/gdm/Xsession: + columnNumber (number) 0
Jun  1 10:11:44 wark /etc/gdm/Xsession: + inner (object) null
Jun  1 10:11:44 wark /etc/gdm/Xsession: + data (object) null
Jun  1 10:11:44 wark /etc/gdm/Xsession: + location (object) JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079
Jun  1 10:11:44 wark /etc/gdm/Xsession: *
Jun  1 10:11:44 wark /etc/gdm/Xsession: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Jun  1 10:11:44 wark /etc/gdm/Xsession: Exception (error clearing message pane)
Jun  1 10:11:44 wark /etc/gdm/Xsession: -- Exception object --
Jun  1 10:11:44 wark /etc/gdm/Xsession: + toString (function) 3 lines
Jun  1 10:11:44 wark /etc/gdm/Xsession: + message (string) 'Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + result (number) 2147942487
Jun  1 10:11:44 wark /etc/gdm/Xsession: + name (string) 'NS_ERROR_ILLEGAL_VALUE'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + filename (string) 'chrome://messenger/content/msgMail3PaneWindow.js'
Jun  1 10:11:44 wark /etc/gdm/Xsession: + lineNumber (number) 1079
Jun  1 10:11:44 wark /etc/gdm/Xsession: + columnNumber (number) 0
Jun  1 10:11:44 wark /etc/gdm/Xsession: + inner (object) null
Jun  1 10:11:44 wark /etc/gdm/Xsession: + data (object) null
Jun  1 10:11:44 wark /etc/gdm/Xsession: + location (object) JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079
Jun  1 10:11:44 wark /etc/gdm/Xsession: *


Error Console Logs:
Timestamp: 02/06/15 13:07:09
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Source File: resource:///modules/errUtils.js
Line: 96

Timestamp: 02/06/15 13:07:09
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 02/06/15 13:07:09
Error: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1079"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 31

[Andrei.Pozolotin]

same symptoms on ubuntu 15.04 thunderbird 38.2.0; workaround is to switch view/layout back/forth

Comment 32

[Andrei.Pozolotin]

more stack traces
-----------------

 [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1063"  data: no]
Exception (error clearing message pane)
-- Exception object --
+ toString (function) 3 lines
+ message (string) ''
+ result (number) 2147942487
+ name (string) 'NS_ERROR_ILLEGAL_VALUE'
+ filename (string) 'chrome://messenger/content/msgMail3PaneWindow.js'
+ lineNumber (number) 1063
+ columnNumber (number) 0
+ inner (object) null
+ data (object) null
+ stack (string) 631 chars
+ location (object) JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1063
*
-- Stack Trace --
ClearMessagePane@chrome://messenger/content/msgMail3PaneWindow.js:1063:0
MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:148:4
summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:2
MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.js:337:6
MessageDisplayWidget_onSelectedMessagesChanged@chrome://messenger/content/messageDisplay.js:240:11
FolderDisplayWidget_summarizeSelection@chrome://messenger/content/folderDisplay.js:1350:11
ThreadPaneSelectionChanged@chrome://messenger/content/threadPane.js:291:2
onselect@chrome://messenger/content/messenger.xul:1:0
[Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1063"  data: no]
Exception (error clearing message pane)
-- Exception object --
+ toString (function) 3 lines
+ message (string) ''
+ result (number) 2147942487
+ name (string) 'NS_ERROR_ILLEGAL_VALUE'
+ filename (string) 'chrome://messenger/content/msgMail3PaneWindow.js'
+ lineNumber (number) 1063
+ columnNumber (number) 0
+ inner (object) null
+ data (object) null
+ stack (string) 402 chars
+ location (object) JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1063
*
-- Stack Trace --
ClearMessagePane@chrome://messenger/content/msgMail3PaneWindow.js:1063:0
MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:148:4
summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:2
MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.js:337:6
MessageDisplayWidget__wrapShowSummary@chrome://messenger/content/messageDisplay.js:352:4

Comment 33

[WADA:World Anti-bad-Duping Agency]

(In reply to Andrei.Pozolotin from comment #32)
> -- Stack Trace --
> ClearMessagePane@chrome://messenger/content/msgMail3PaneWindow.js:1063:0
> MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.
> js:148:4
> summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:2
> MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.
> js:337:6
> MessageDisplayWidget_onSelectedMessagesChanged@chrome://messenger/content/
> messageDisplay.js:240:11
> FolderDisplayWidget_summarizeSelection@chrome://messenger/content/
> folderDisplay.js:1350:11
> ThreadPaneSelectionChanged@chrome://messenger/content/threadPane.js:291:2
> onselect@chrome://messenger/content/messenger.xul:1:0

If single message only is clicked at Thread pane, load of the clicked message should occur at Message pane, because the execption in ClearMessagePane() due to "messagePane.location is undefined or null(or messagePane=null or undefined)" is caught by try/catch and the exception is merely logged by ClearMessagePane().

If ordinal message load to Messgse pane by single mail click at Thread pane, load of the message is requested after call of ClearMessagePane().
I can't imagine reason why messagePane.location.href=about:blank in ClearMessagePane() fails.
If ordinal message load to Messgse pane by single mail click at Thread pane, no one tries to unload alreaady hown message at Message paane, "messagePane.location.href==about:blank or URI of already loaded messaage" should be set.
I think "messagePane.location==undefined or null" can occur when someone tried to unload at Message pane(or reconstructed  or then requested ClearMessagePane(). 


In stack trace, olderDisplayWidget_summarizeSelection, MessageDisplayWidget_showSummary, summarizeFolder, is seen.
These code has logic for
   (a) "Show summary of multiple selected messages when selected message count>0",
   (b) "Show folder when selected message count==0",
   (c) "Display selected message i Message pane when selected message count==1".
Function for (a) is invoked only when mail.operate_on_msgs_in_collapsed_threads=true(defaut is true).

It may be interfere by code for (a) "Show summary of multiple selected messages".
To all problem reporters:
Do you see your problem with mail.operate_on_msgs_in_collapsed_threads=false?

My question.
   http://mxr.mozilla.org/comm-central/source/mail/base/content/folderDisplay.js#1368
     FolderDisplayWidget_summarizeSelection() does do
        return this.messageDisplay.onSelectedMessagesChanged();
   http://mxr.mozilla.org/comm-central/source/mail/base/content/messageDisplay.js#323
     MessageDisplayWidget_showSummary(aIsCallback) has logic like
        let selectedCount = this.folderDisplay.selectedCount;
        if (selectedCount == 1)
            return true;
        if (this.folderDisplay.selectedCount == 0) { ... } else { ... }
  I think this.folderDisplay is reference to window.gFolderDisplay object of current messanger window.
  Is window.gFolderDisplay==1 guarntiied when FolderDisplayWidget_summarizeSelection() and
    MessageDisplayWidget_showSummary(aIsCallback) is invoked after click of a message at Thred pane?

Comment 34

[Andrei.Pozolotin]

1) here is my simplest use case: 
* make brand new clean Thunderbird install (no extensions)
* leave all other settings as defaults
* the only custom configured item is IMAP server account
then the bug is 100% reproducible when I rename any IMAP folder (trace above #32)

2) so we can see that IMAP folder rename fires up sequence of calls,
terminating in [ClearMessagePane] blow up

3) either way, [ClearMessagePane] probably should be made more robust
against race conditions, broken logic, wrong assumptions, etc;
Thunderbird code is way to convoluted to "work as it should"
I guess its better do defensive programming

Comment 35

[Andrei.Pozolotin]

here is improved workaround :-)

use: https://addons.mozilla.org/en-us/thunderbird/addon/custom-buttons/

to add "folder rename" (or other offensive event) listener which then kicks the view on event:

ChangeMailLayoutForCommand("cmd_viewVerticalMailLayout");
ChangeMailLayoutForCommand("cmd_viewClassicMailLayout");

Comment 36

[WADA:World Anti-bad-Duping Agency]

adding exception data in bug summaary for ease of search.

Comment 37

[WADA:World Anti-bad-Duping Agency]

(In reply to Andrei.Pozolotin from comment #35)
> to add "folder rename" (or other offensive event) listener which then kicks the view on event:
>   ChangeMailLayoutForCommand("cmd_viewVerticalMailLayout");
>   ChangeMailLayoutForCommand("cmd_viewClassicMailLayout");


(Q1) Why "folder rename" is trigger of the workaround?
Following phenomenon or similar one is involved in your "Inability to view message body in the message pane"?
 1. Rename IMAP folder(Offline-Use=Off may be relevant)
    => Folder name at Folder pane is not updated, Thread pane is not updated (this is known phenomenon)
    => If a mail is clicked at Thread pane, Tb requests with old Mbox name => server returns "doesn't exist"
       Error alert is shown in this case in my environment.
    => Message pane is not refreshed, because fetch of mail data fails.
 2. Collapse IMAP account then Expand it at Folder pane
    => Folder pane is updated by new name after rename folder.

(Q2) Once the exception occurred due to "location.href access when location=undefined/null", 
     any attempt to show message by message click fails until you do the recovery/workaround?
     If so, the exception occurs upon each click of mail at Thread pne?
(Q3) If problem won't disappear until the workaround, can following be a recovery procedure?
     Open second messenger window(Folder Context Menu, Open in new window),
     then close first messenger window.

Comment 38

[WADA:World Anti-bad-Duping Agency]

try/catch in ClearMessagePane() 
> 1111   try {
> 1112     // This can fail because cloning imap URI's can fail if the username
> 1113     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> 1114     let messagePane = GetMessagePaneFrame();
> 1115     // If we don't do this check, no one else does and we do a non-trivial
> 1116     // amount of work.  So do the check.
> 1117     if (messagePane.location.href != "about:blank")
> 1118       messagePane.location.href = "about:blank";
> 1119   } catch(ex) {
> 1120       logException(ex, false, "error clearing message pane");
> 1121   }
messagePane object is obtained by;
  messagePane = GetMessagePaneFrame();
> http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1034
> 1034 function GetMessagePaneFrame()
> 1035 {
> 1036   // We must use the message pane element directly here, as other tabs can
> 1037   // have browser elements as well (which could be set to content-primary,
> 1038   // which would confuse things with a window.content return).
> 1039   return document.getElementById("messagepane").contentWindow;
> 1040 }
As written in comment, multiple elements with id=messagepane are defined in Thunderbird.
   Multiple messaanger windows can exist in a Thunderbird instance
     A messenger window can have multiples Tab(tabmail),
       A Tab for a 3 pane window has one element with id=messagepane
       A Tab for other than 3 pane window usually doesn't have element with id=messagepane
Object like window, document depends on Context of JavaScript execution.
Is "document object referred in GetMessagePaneFrame()" lways guranteed as one which ClearMessagePane() expects?

To bug opener:
Do you see your problem with single messenger window in Tb, with single Tab only in the messenger window?

Comment 39

[WADA:World Anti-bad-Duping Agency]

If document.getElementById("messagepane") is executed under Context of messenger.xul window(e.g. Toolbar Button), following is neeeded to obtain required element of id=messagepane in required Tab.
  1. (window).document.getElementById(xxx) for required Tab, or obtain active Tab.
  2. At required Tab, TabObject.document.getElementById("messagepane")

Is ClearMessagePane() invoked with TabMail Context(or lower Context, and higher Context than required element of id=messagepane) always, regardless of current Tab or current Context when ClearMessagePane() is called?

I think code like following is better to narrow down.
> try {
>   let messagePane = GetMessagePaneFrame();
>   if      (!messagePane)               { write error log }
>   else if (!messagePane.location)      { write error log }
>   else if (!messagePane.location.href) { write error log }
>   else if (messagePane.location.href != "about:blank")
>            messagePane.location.href = "about:blank";
>   // else { no need to do nothing, because about:blank is already set }
> } catch(ex) {
>     logException(ex, false, "error clearing message pane");
> }

Comment 40

[:aceman]

I was taught there is only a single instance of the various panes per TB window, regardless of number of tabs. So are you sure the problem here is about document.getElementById("messagepane") not being able to find the element (or having more of them)?

Comment 41

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #40)
> I was taught there is only a single instance of the various panes per TB
> window, regardless of number of tabs. So are you sure the problem here is
> about document.getElementById("messagepane") not being able to find the
> element (or having more of them)?

I don't know whether "single messenger with single Tab" cases and "multi messengers with multi Tabs" cases are always absolutely same or not same.
And, I don't know whether "multi messengers with multi Tabs" case can cause problem.
I merey counted up a possible suspect with no evidence, by code looking only, based on "Exception upon  messagePane.location.href reference" only.

e

Comment 42

[Andrei.Pozolotin]

(In reply to WADA from comment #37)

1) let me clarify the test case:
* on brand new install with single configured imap server
* using default layout "classic view", single mail tab only
* any rename of any imap folder results in a "broken view"
* now, the "broken view" means:
* when I navigate from folder to folder (any folder, not just the renamed one), the message list appears OK
* when I click on any message in the message list, the following looks broken:
* message header is collapsed and does not show email headers
* message pane is blank and does not show email body
* console log / javascript log reports stack traces shown in #33 above
* this "broken view" is fixed only by restart

2) let me clarify the "work around":
* since is is "folder rename" action that breaks the view
* the solution was to override [gFolderTreeController.renameFolder]
* with some custom code that "fixes the view w/o restart"

3) as it was found by others above, the following sequence (manual or coded) "fixes the view w/o restart":
ChangeMailLayoutForCommand("cmd_viewVerticalMailLayout"); ChangeMailLayoutForCommand("cmd_viewClassicMailLayout");

4) so here is the override code for [gFolderTreeController.renameFolder], 
loaded on init by custom-buttons extension, works reliably here so far

function override_rename_folder() {
   var source = gFolderTreeView.getSelectedFolders()[0];
   var parent = source.parent;
   
   Services.console.logStringMessage(" source: " + source.name);
   
   function rename_folder(name, uri) {

      function show_folder() {
        var target=parent.getChildNamed(name); // locate new renamed folder
        gFolderTreeView.selectFolder(target, true); // open new renamed folder
        gFolderDisplay.show(target); // force new renamed folder message pane refresh
      }

      function kick_view() { // voodoo magic work around to fix the broken view w/o restart
        ChangeMailLayoutForCommand("cmd_viewVerticalMailLayout");
        ChangeMailLayoutForCommand("cmd_viewClassicMailLayout");
        setTimeout(show_folder, 500); // force folder display after a view switching delay
      }
   
     gFolderTreeView.selection.clearSelection();
     gFolderDisplay.show(null);
     
     source.rename(name, msgWindow); // actually rename source to target
     
     setTimeout(kick_view, 500); // force work around after a folder processing delay

   }
   
   window.openDialog(
      "chrome://messenger/content/renameFolderDialog.xul",
      "",
      "chrome,modal,centerscreen",
      {preselectedURI: source.URI, okCallback: rename_folder, name: source.prettyName}
   );
}

Comment 43

[Andrei.Pozolotin]

(In reply to WADA from comment #37)

yes, need to clarify: in multi-tab or multi-window scenario, the "fix" works only
for the current tab/window, all other tab/window s remain broken, 
until their own "kick-view" invocation

Comment 44

[Andrei.Pozolotin]

(In reply to WADA from comment #37)

> (Q1) Why "folder rename" is trigger of the workaround?
see #42, clarified

> (Q2) Once the exception occurred due to "location.href access when
see #42, the exception occurs upon each click new folder, not on mail at Thread pane in the same folder

> (Q3) If problem won't disappear until the workaround, can following be a
> recovery procedure?
YES, to some degree:
a) if I open new TAB, both old tab and new tab remain broken
b) if I open new WINDOW old window remains broken, but new window now works OK and w/o exceptions

Comment 45

[WADA:World Anti-bad-Duping Agency]

"Multiple 3pane window tabs in a messenger window" is relevant to problem?

I think that, if problem stated in comment in source code of GetMessagePaneFrame() occurs, similar issue due to "used window context when a module is invoked" can occur on document.getElementById("messagepane").contentWindow; in the GetMessagePaneFrame().

messagePane object is obtained by;
  messagePane = GetMessagePaneFrame();
> http://mxr.mozilla.org/comm-central/source/mail/base/content/msgMail3PaneWindow.js#1034
> 1034 function GetMessagePaneFrame()
> 1035 {
> 1036   // We must use the message pane element directly here, as other tabs can
> 1037   // have browser elements as well (which could be set to content-primary,
> 1038   // which would confuse things with a window.content return).
> 1039   return document.getElementById("messagepane").contentWindow;
> 1040 }

Comment 46

[Merike Sell (:merike)]

I just ran into this with 43.0a2.

(In reply to WADA from comment #39)
> I think code like following is better to narrow down.
> > try {
> >   let messagePane = GetMessagePaneFrame();
> >   if      (!messagePane)               { write error log }
> >   else if (!messagePane.location)      { write error log }
> >   else if (!messagePane.location.href) { write error log }
> >   else if (messagePane.location.href != "about:blank")
> >            messagePane.location.href = "about:blank";
> >   // else { no need to do nothing, because about:blank is already set }
> > } catch(ex) {
> >     logException(ex, false, "error clearing message pane");
> > }

In my case executing
> var w = Components.classes["@mozilla.org/appshell/window-mediator;1"].getService(Components.interfaces.nsIWindowMediator).getMostRecentWindow("mail:3pane"); w.document.getElementById("messagepane").contentWindow.location
in error console (debugger does not work for me currently) gives
>Timestamp: 18.10.2015 13:54:13
Error: NS_ERROR_ILLEGAL_VALUE: 

contentWindow itself still gives [object Window].

Is there a way to recover from such a case? I don't know when or why tb stopped displaying messages, only that it worked yesterday, didn't work today morning and that I didn't restart tb meanwhile. I'm not restarting tb yet so can check for a few other things if you tell me what to check for :)

Comment 47

[Wayne Mery (:wsmwk)]

(In reply to Merike (:merike) from comment #46)
>...
> Is there a way to recover from such a case? I don't know when or why tb
> stopped displaying messages, only that it worked yesterday, didn't work
> today morning and that I didn't restart tb meanwhile. I'm not restarting tb
> yet so can check for a few other things if you tell me what to check for :)

Comment 48

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #47)
> (In reply to Merike (:merike) from comment #46)
> >...
> > Is there a way to recover from such a case? I don't know when or why tb
> > stopped displaying messages, only that it worked yesterday, didn't work
> > today morning and that I didn't restart tb meanwhile. I'm not restarting tb
> > yet so can check for a few other things if you tell me what to check for :)

> Flags: needinfo?([e-mail])

Sorry, but I don't know.

Comment 49

[Magnus Melin [:mkmelin]]

Nothing comes to mind, sorry.

Comment 50

[capndave]

Original reporter here.

I'll try to keep my comments constructive, but ...
this issue has been the stone in my shoe (and apparently others)
for the last 13 months and since v31.

The workaround has been for me to use v24.8.1, but yesterday I
was mandated by our sysadmins to install v38.3.0.  This was a
clean install, not an upgrade from v24.8.1.  It was a clean Win 7 install.
The imap folders downloaded and indexed overnight.
Low and behold, within literally 1 minute of navigating the folder structure
I could not view the message in the pane (SAME ISSUE).  I have since
spent the morning rebooting Thunderbird literally 5 minutes to.
For pity's sake!

Fresh error log:
Timestamp: 11/17/2015 9:51:13 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34
Timestamp: 11/17/2015 9:51:13 AM
Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1087"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35
Timestamp: 11/17/2015 9:51:13 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34
Timestamp: 11/17/2015 9:51:13 AM
Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1087"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 51

[capndave]

I hate to do it (again) but flagging this as a blocker, because in all reality, that is what it is.
I know it will get bumped back down again, but this time at least it seems others are also starting
to hit this issue.

Comment 52

[Wayne Mery (:wsmwk)]

Thanks for the update.

bug 1062408, with different steps, describes similar symptoms.  Also a regression without a useful identified regression range, like this bug.  Having a good regression range will make it far easier to get this fixed.

You'll want to bisect the range of nightly builds (comm-central directories) between
https://archive.mozilla.org/pub/thunderbird/nightly/2013/06/2013-06-25-03-12-45-comm-central/
and
https://archive.mozilla.org/pub/thunderbird/nightly/2014/04/2014-04-29-03-02-01-comm-central/

(note also bug 545933. But it's not a regression of the same time period.)


(In reply to capndave from comment #51)
> I hate to do it (again) but flagging this as a blocker, because in all
> reality, that is what it is.
> I know it will get bumped back down again

correct. see definitions at https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity

Comment 53

[capndave]

Thunderbird 45 just released.
Same error.

Timestamp: 4/28/2016 12:21:12 PM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 4/28/2016 12:21:12 PM
Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Timestamp: 4/28/2016 12:21:12 PM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 4/28/2016 12:21:12 PM
Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 54

[Wayne Mery (:wsmwk)]

(In reply to capndave from comment #53)
> Thunderbird 45 just released.
> Same error.

indeed, because there have been no patches.

can you find a regression range for us?

Use Moz Regression tool https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Mozmill/How_to_do_regression_testing download from https://github.com/mozilla/mozregression

Comment 55

[info]

also can verify this error in the current version.

Actually it occured shortly after the move folder preview pane error has been resolved.

It seemed to be connected to attachement plugins, but even after deactivating those the error persisted.

After all I have to say: Now the preview pane still remains emty again after a folder move.

Back to square one. 

Zeitstempel: 21.11.2016 13:10:40
Fehler: error clearing message pane
Quelldatei: resource:///modules/errUtils.js
Zeile: 34

Zeitstempel: 21.11.2016 13:10:40
Fehler: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
Quelldatei: resource:///modules/errUtils.js
Zeile: 35

It is kind of tragic that an error which was aleady fixed in a prior version reappears again.

Comment 56

[Wayne Mery (:wsmwk)]

aceman, can you work of a fix for this?

I just can't take it anymore. Anyone doing significant account/folder maintenance is going to be burned by this big time. (which is happening to me because of my annual mail cleanup process) 

I reconfirm Gregr's regression range cited in bug 1120361 comment 16 - 2014-01-13 good, 2014-01-14 bad. So http://hg.mozilla.org/comm-central/pushloghtml?startdate=2014-01-13+03%3A00&enddate=2014-01-14+05%3A00 = http://hg.mozilla.org/comm-central/rev/0456c50549f6 - Port bug 331376 - nsIDocShellTreeItem and nsIDocShellTreeNode should be merged

Comment 59

[WADA:World Anti-bad-Duping Agency]

Why ClearMessagePane and "approximately 25% of the time" in comment #0?
3pane tab version of bug 520115 in message window/message tab?

To all problem reporters:
 Do you open stand alone message window and/or message tab?
 If yes, do you see similar phenomenon to bug 520115 when you see problem of this bug?

Comment 60

[Wayne Mery (:wsmwk)]

aceman, so as you stated in irc, the other set of steps is
 1. click on and display a message
 2. drag a folder somewhere else
 3. click on some message. 
No failure if you skip step 1. 

also, check comment 42 (I haven't tried it myself)

Comment 61

[WADA:World Anti-bad-Duping Agency]

In Daily, following error was shown.
> ReferenceError: reference to undefined property "URI"[Learn More]  moveCopy.js:285:1

1. Show a main in local folder named FolderX at messagepane of 3pane tab.
2. Rename FolderX tio FolderY
   => messagepane was cleared, nothing is selected at thread pane
3. Above error was shown in Error Console.

If standalone message window for the mail is opened, following exception was shown in Error Console.
> [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgDBHdr.messageId]"  nsresult: 
> "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/folderDisplay.js ::
>  FolderDisplayWidget_saveSelection/this._savedSelection.messages< :: line 316"  data: no]  (unknown)
> TypeError: this.folderDisplay.view.dbView is null[Learn More]  messageWindow.js:254:1

From perspective of message window/message tab/messagepane or dbView, "folder rename while message is shown" and "compact while message is shown" are similar event, because Compact can be called "created nstmp folder, delete FolderX, rename nstmp to FolderX".

When IMAP and imap deleted model=just mark it as deleted, issue like exception was not observed when Compact.
1. At FolderX, UID=X has \Deleted flag. Show it in stand alone message window(and in messagepane too).
2. Compact FolderX => UID=X is removed from server because EXPUNGE is issued by Tb.
3. Message window is kept open, but UID=X doesn't exist any more, so Reply/Forward etc. can do nothing.

Which is better when mail doesn't exist any more?
  imap              : Keep message window open
  local mail folder : Close message window

As soon in above imap case, problem like exception doesn't look to occur easily in imap.
aceman, some code still expect messageKey=Offset?

Comment 62

[capndave]

I am the original reporter.  Happy to see this issue getting the head of steam it has always deserved.

To clear some things up:
- Some parts of Comment #0 (mine) did not hold up.  The "25% of the time" is incorrect.  It's always.
- The issue does Not require renaming folder -or- moving folders.  Those actions may help speed up the reproducing of the issue, but it's not required.  I hit these all the time during basic navigation.
- The issue does Not occur with 24.8.1.  The issue starts with v 31.  I have not tried the betas in between.
- It is platform independent.  I hit this on Windows, Linux, Mac.
- A clean install does not help.  One of my tests was to do a fresh O/S install, install Thunderbird and and hit this within 2 minutes of first run.
- Using Thunderbird 45.1.1 - the "trio" of errors is the same as in Comment #6.  Perhaps the line numbers can change based on the codeine, but the error messages are the same.

Comment 63

[capndave]

Also, I do not need to 'compact' (ie., 520115) in order for this to reproduce.
To answer another question - I view my messages in the pane, not a new window.

Comment 64

[WADA:World Anti-bad-Duping Agency]

(In reply to capndave from comment #62)

Thanks for summarizing problem.
I'm now confident that this bug and bug 520115 which I observed while testing Compact are almost identical phenomenon/issue.

Please fill following table.
>                   Rename folder         Move folder           Compact folder
>                    while message in it   while message in it   while message in it
>                    is shown at:          is shown at:          is shown at:
>                                                               Offset is changed  Offset is not changed  Shown mail is expunged
>                                                               (local folder)     (local folder)         (imap)             
> message pane of
>   3pane Tab        ?                     ?                     ?                  ?                      ?          
> message pane of
>   message Tab      ?                     ?                     ?                  ?                      ?
> message pane of
>   message Window   ?                     ?                     ?                  ?                      ?

From persipective of message display, Compact = create nstmp folder from FolderX, delete FolderX, rename nstmp folder to FolderX.
So, similar phenomenon to this bug(rename folder/move folder) is observed in bug 520115 in Compact case too.
  Folder disappered while message in it is shown at messagepane,
  so the shown message at messagepane also disappered while message is viewed.

Because Auto-Compact invokes actual Compact operation if deleted mail exist in local FolderX,
and because Auto-Compact silently invokes Compact operation if "dialog before invoking auto-compact" is disabled,
Compact on FolderX can run while a message in FolderX is shown at messagepane of 3pane Tab, message Tab, message Window.
Once "dialog before invoking auto-compact" was disabled by unchecking option for the dialog at first dialog,
there is no UI to re-enable the option for "dialog before invoking auto-compact"(set via Config Editor, restart Thunderbird, is required).
So, "dialog before invoking auto-compact" is usually disabled.
Therefore, user usually can not be aware of "Compact was invoked on FolderX".

If user opens message Window or message Tab, user can easily be aware of problem, because message Window or message Tab is closed when problem happened.
But if user viewed 3pane Tab only, problem is usually not exposed because 3pane tab is not closed.
Problem is exposed as "Exception in ClearMessagePane" only when some other conditions unfortunately occurred.

Further, phenomenon is different between local mail folder and imap folder, because mechanism is different between local mail folder and imapo folder.

Comment 65

[WADA:World Anti-bad-Duping Agency]

I could observe exception in ClearMessagePane of this bug in my environment at last, after reading comment #0 again and your new summarizing of this bug.

> Timestamp: 2016/12/21 23:13:29
> Error: error clearing message pane
> Source File: resource:///modules/errUtils.js
> Line: 34
> 
> Timestamp: 2016/12/21 23:13:29
> Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
> Source File: resource:///modules/errUtils.js
> Line: 35
> 
> Timestamp: 2016/12/21 23:13:29
> Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
> Source File: resource:///modules/errUtils.js
> Line: 35
> 
> Timestamp: 2016/12/21 23:13:29
> Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no]
> Source File: resource:///modules/errUtils.js
> Line: 35

[STR]
(1) Thunderbird 45.1.0, messenger window, 3pane Tab is active tab.
    Gmail IMAP folder named FolderX is selected at folder pane,
    a message in the imap FolderX is selected at thread pane
    -> the selected message in imap FolderX is shown in id=messagepane of the active 3pane tab.
(2) Rename FolderX to FolderY, via. context menu of the selected imap FolderX at folder pane
    -> above error message is shown in Error Console of Thderbird 45.
    -> messagepane is cleared(URL=about:blank), no selected message at thread pane 
This is same as procedure you explained many times in this bug.

I checked only with "standalone message window/message tab && Compact of local mail folder" in bug 520115, because main problem reported by users was "message window/message tab was closed when compact was executed".
I couldn't be aware of similarity in "3pane tab and message window/tab" and similarity in "rename/move folder and compact".
I couldn't be aware of difference between imap and local folders. 
I was confused by different error/exception in different test procedure/conditions on different Thunderbird builds.

Comment 66

[WADA:World Anti-bad-Duping Agency]

New table which should be filled. It's required for each Thunderbird build.
>                   Rename folder         Move folder           Compact folder
>                    while message in it   while message in it   while message in it
>                    is shown at:          is shown at:          is shown at:
>                                                               Offset is changed  Offset is not changed  Shown mail is expunged
>                   (local) (imap)        (local) (imap)        (local folder)     (local folder)         (imap)             
> message pane of
>   3pane Tab        ?       ?             ?       ?             ?                  ?                      ?          
> message pane of
>   message Tab      ?       ?             ?       ?             ?                  ?                      ?
> message pane of
>   message Window   ?       ?             ?       ?             ?                  ?                      ?

Comment 67

[WADA:World Anti-bad-Duping Agency]

Problem is perhaps.
  When mail of messageKey=X in FolderX is shown in messagepane of 3pane tab or message window/tab,
  if FolderX disappered then messageKey=X in FolderX is also disappeared,
  refreshing of messagepane is invoked at each 3pane tab and message window/message tab.
  Because conditions/invoked task/timing when task runs, are different, diffrent phenomenon/exception is observed.
  When exception occurs, message window/message tab is currently closed, but 3pane tab is never closed by such exception.

Culprit is not module who generated exception.
Culprit is who invoked modules even though invoking the module is never appropriate or alliowed action.

In such case, if folder rename/folder move, or if relevant message is not removed by Compact,
trying to show corresponding message in folder after rename/move/compact is not impossible.
However, if the shown message in imap folder was expunged by Compact or if the shown message was deleted while the message is shown in messagepane, reasonable action is clear messagepane, close message tab, close message window, because the shown message never exists any more.

As seen in imap/compact/expunged case, message tab/message window is not closed in this case because exception doesn't occur.
However, Reply/Forward etc. does(can) do nothing on shown message because shown message never exists any more.
I believe this is also problem.

Comment 68

[WADA:World Anti-bad-Duping Agency]

aceman, what do you think about problem of this bug and bug 520115?

Comment 69

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is folder events notified to folder event listener when move folder, rename folder, compact folder.
  AnnouncerGoingAway -> cleanup up work is perhaps invoked -> exception occurs somewhere -> if message tab/window, closed
  -> ItemAdded/ItemRemoved, ItemRemoved/ItemAdded, CompactCompleted, are notified
  -> Thread pane(dbView), messagepane are refreshed
AnnouncerGoingAway doesn't occur when Repair Folder, so this bug doesn't occur.

(1) Move Fiolder
> DateTime=2016/12/21 23:09:05.975 GMT, EventType=DBOpened, MsgDB=mailbox://nobody@Local%20Folders/Test/S1/S2X
> DateTime=2016/12/21 23:09:06.023 GMT, EventType=FolderLoaded, FolderURI=mailbox://nobody@Local%20Folders/Test/S1/S2X
> DateTime=2016/12/21 23:09:17.714 GMT, EventType=AnnouncerGoingAway
> AnnouncerGoingAway_instigator : [xpconnect wrapped nsIDBChangeAnnouncer]
>   AnnouncerGoingAway_instigator / Property
>   AnnouncerGoingAway_instigator / Function
>     AddListener = function AddListener()
>     NotifyAnnouncerGoingAway = function NotifyAnnouncerGoingAway()
>     NotifyHdrAddedAll = function NotifyHdrAddedAll()
>     NotifyHdrChangeAll = function NotifyHdrChangeAll()
>     NotifyHdrDeletedAll = function NotifyHdrDeletedAll()
>     NotifyJunkScoreChanged = function NotifyJunkScoreChanged()
>     NotifyParentChangedAll = function NotifyParentChangedAll()
>     NotifyReadChanged = function NotifyReadChanged()
>     QueryInterface = function QueryInterface()
>     RemoveListener = function RemoveListener()
> 
> DateTime=2016/12/21 23:09:17.814 GMT, EventType=Folder_ItemAdded, item.URI=mailbox://nobody@Local%20Folders/Test/X1/S2X, parentItem.URI=mailbox://nobody@Local%20Folders/Test/X1
> DateTime=2016/12/21 23:09:17.819 GMT, EventType=Folder_ItemRemoved, item.URI=mailbox://nobody@Local%20Folders/Test/S1/S2X, parentItem.URI=mailbox://nobody@Local%20Folders/Test/S1

(2) Rename Folder
> DateTime=2016/12/21 22:52:43.430 GMT, EventType=DBOpened, MsgDB=mailbox://nobody@Local%20Folders/Test/S1/S2
> DateTime=2016/12/21 22:52:43.488 GMT, EventType=FolderLoaded, FolderURI=mailbox://nobody@Local%20Folders/Test/S1/S2
> DateTime=2016/12/21 22:53:08.632 GMT, EventType=MsgDB_was_Closed, MsgDB=mailbox://nobody@Local%20Folders/Test, Info=Closed between 2016/12/21 22:52:08.630 GMT and 2016/12/21 22:53:08.631 GMT
> DateTime=2016/12/21 22:53:28.248 GMT, EventType=AnnouncerGoingAway
> AnnouncerGoingAway_instigator : [xpconnect wrapped nsIDBChangeAnnouncer]
>   AnnouncerGoingAway_instigator / Property
>   AnnouncerGoingAway_instigator / Function
>     AddListener = function AddListener()
>     NotifyAnnouncerGoingAway = function NotifyAnnouncerGoingAway()
>     NotifyHdrAddedAll = function NotifyHdrAddedAll()
>     NotifyHdrChangeAll = function NotifyHdrChangeAll()
>     NotifyHdrDeletedAll = function NotifyHdrDeletedAll()
>     NotifyJunkScoreChanged = function NotifyJunkScoreChanged()
>     NotifyParentChangedAll = function NotifyParentChangedAll()
>     NotifyReadChanged = function NotifyReadChanged()
>     QueryInterface = function QueryInterface()
>     RemoveListener = function RemoveListener()
> 
> DateTime=2016/12/21 22:53:28.372 GMT, EventType=Folder_ItemRemoved, item.URI=mailbox://nobody@Local%20Folders/Test/S1/S2, parentItem.URI=mailbox://nobody@Local%20Folders/Test/S1
> DateTime=2016/12/21 22:53:28.374 GMT, EventType=Folder_ItemAdded, item.URI=mailbox://nobody@Local%20Folders/Test/S1/S2X, parentItem.URI=mailbox://nobody@Local%20Folders/Test/S1

(3) Compact Folder
> DateTime=2016/12/21 23:01:33.922 GMT, EventType=DBOpened, MsgDB=mailbox://nobody@Local%20Folders/Test/S1/S2X
> DateTime=2016/12/21 23:01:33.961 GMT, EventType=FolderLoaded, FolderURI=mailbox://nobody@Local%20Folders/Test/S1/S2X
> DateTime=2016/12/21 23:01:45.287 GMT, EventType=AnnouncerGoingAway
> AnnouncerGoingAway_instigator : [xpconnect wrapped nsIDBChangeAnnouncer]
>   AnnouncerGoingAway_instigator / Property
>   AnnouncerGoingAway_instigator / Function
>     AddListener = function AddListener()
>     NotifyAnnouncerGoingAway = function NotifyAnnouncerGoingAway()
>     NotifyHdrAddedAll = function NotifyHdrAddedAll()
>     NotifyHdrChangeAll = function NotifyHdrChangeAll()
>     NotifyHdrDeletedAll = function NotifyHdrDeletedAll()
>     NotifyJunkScoreChanged = function NotifyJunkScoreChanged()
>     NotifyParentChangedAll = function NotifyParentChangedAll()
>     NotifyReadChanged = function NotifyReadChanged()
>     QueryInterface = function QueryInterface()
>     RemoveListener = function RemoveListener()
> 
> DateTime=2016/12/21 23:01:45.328 GMT, EventType=CompactCompleted, FolderURI=mailbox://nobody@Local%20Folders/Test/S1/S2X, Comment=MsgDB Listner is re-registered

Comment 70

[WADA:World Anti-bad-Duping Agency]

Following is AnnouncerGoingAway event handler of DBView.
> https://dxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgDBView.cpp#6307
> NS_IMETHODIMP nsMsgDBView::OnAnnouncerGoingAway(nsIDBChangeAnnouncer *instigator)
itemadded/itemRemoved/CompactCompleted are notified after 50msec to 100msec in test.
Problem is "While doing job for AnnouncerGoingAway, job for itemadded/itemRemoved/CompactCompleted runs, then contention occurs"?

Comment 71

[:aceman]

WADA, have you looked at the regression range cited in comment 56?
Using bisecting there is a candidate patch that could have caused this:
http://hg.mozilla.org/comm-central/rev/0456c50549f6

Can you spot any error in it?

Wayne, is there a list of checkins into m-c for that day?

Comment 72

[WADA:World Anti-bad-Duping Agency]

(In reply to :aceman from comment #71)
> WADA, have you looked at the regression range cited in comment 56?

No, bug 520115 is pretty old problem, although exception depends on build.
If regression window is already found and is correct, why problem was not analyzed in that bug when regression window was found? Why that bug was duped to this bug despite that regression window was found in that bug?

It looks that exception depends on case, and problem after the exception depends on exception and case/condition.
If message tab/window, tab/window is closed, but if messenger 3pane tab. messagepane is broken.
I misunderstood about cause and result. I thought culprit was exception, but culprit is who generated cause of exception.

Anyway, all of messagepane is broken in this bug's case, so phenomenon itself is critical for user.
But recovery procedure is pretty simple/easy, because cause of external problem is completely broken messagepane.
  Recovery procedure: Open new messanger window, close old messenger window.
And, STR is pretty simple, as stated by bug opener of this bug repeatedly.

Comment 75

[WADA:World Anti-bad-Duping Agency]

[e-mail](bug opener), can you check regression window by trunk nightly? (see User Story, please)

Comment 76

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #71)
> WADA, have you looked at the regression range cited in comment 56?
> Using bisecting there is a candidate patch that could have caused this:
> http://hg.mozilla.org/comm-central/rev/0456c50549f6
> 
> Can you spot any error in it?
> 
> Wayne, is there a list of checkins into m-c for that day?

sure. as you can imagine, the list is huge. https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-01-13+03%3A00&enddate=2014-01-14+05%3A00  standouts are bug 957479, bug 881487, and of course bug 331376

Note - the regression range is solid. So I think if a patch isn't obvious, then the shorter path to solution and the thing to do here is backout https://hg.mozilla.org/comm-central/rev/0456c50549f6 and see what happens, before spending more time analyzing.

Comment 77

[WADA:World Anti-bad-Duping Agency]

https://hg.mozilla.org/comm-central/pushloghtml?startdate=2014-01-13+03%3A00&enddate=2014-01-14+05%3A00
 bug 331376 touches treeview.

Comment 78

[WADA:World Anti-bad-Duping Agency]

FYI.
Following exception occurs when:
(a) imap folder is renamed while a message in the folder is shown in messagepane, (b) after (a), messagepane is hidden, (c) after (a), other folder is clicked.
i.e. ClearMessagePane is not culprit. ClearMessagePane is victim of broken messagepane, although existence check of XPCOM opject property is better executed by code in case of that object property is not available yet. 
> 20:50:47.730 [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame ::
> chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1093"  data: no] 1 (unknown)

Comment 79

[WADA:World Anti-bad-Duping Agency]

FYI.
About regression window(trunk) :
[2014-01-13] : Exception in ClearMessagePane doesn't occur. i.e. A referred property of XPCOM object is available.
   After folder pane is refersed by new folder name, nothing is shown in thread pane.
   Folder click at folder pane does do nothing.
   Click other folder -> normally executed. Click the renamed folder again -> normally executed.
   Although broken messagepane and exception in ClearMessagePane doesn't occur,
   dbView referesh is not propery executed if "proper refresh of dbView(thread pane) after rename folder" is design.
[2014-01-14] : messagepane is broken, and exception occurs.

Comment 80

[WADA:World Anti-bad-Duping Agency]

Phenomenon :
 Big problem like "broken messagepane" fortunately or unfortunately didn't occur in 3pane Tab upon rename of imap folder.
 But from 2014-01-14 build, big problem can occur in 3pane tab, as window/tab close issue normally occurs in message tab/window.
 Now 3pane tab is member of family.
I think something bad in process after OnAnnouncerGoingAway event was exposed in 3pane tab too by change between 2014-01-13 and 2014-01-14.

Comment 81

[WADA:World Anti-bad-Duping Agency]

Exception in dbView is observed in other cases, and bug 331376 touches treeview, and dbView(thread pane view) actually does do something upon AnnouncerGoingAway event(cleanup of dbView because using folder is lost).
> https://dxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgDBView.cpp#6307
> NS_IMETHODIMP nsMsgDBView::OnAnnouncerGoingAway(nsIDBChangeAnnouncer *instigator).
After exception of this bug, thread pane is cleared because used folder was lost and new folder(renamed folder) is shown at folder pane.

Comment 82

[WADA:World Anti-bad-Duping Agency]

Folder pane(folder tree view) also watches AnnouncerGoingAway/itemRemoved/itemAdded produced by Folder Rename, as seen in "result of folder rename is reflected at folder pane". When new folder is shown at folder pane, if it's selected folder at folder pane, thread pane is refreshed.
I guess contention between AnnouncerGoingAway process at thread pane(dbView) and itemAdded process at folder pane(folderTreeView).

Comment 84

[WADA:World Anti-bad-Duping Agency]

Copying bug 916095 what was held in Depends on: field of bug 1062408, which was closed as a bug, to See Also: field of this bug.

Comment 85

[WADA:World Anti-bad-Duping Agency]

FYI.
By bug 916095, RenameCompleted handler was added to dbViewWrapper.js, and something was done in the eventhandler to resolve problem of bug 916095.
This kind of informstion was lost by duping...

Comment 86

[WADA:World Anti-bad-Duping Agency]

Sorry, correction of comment #84: which was closed as dup of a bug,

Comment 87

[WADA:World Anti-bad-Duping Agency]

> +  _forceOpen: function DBViewWrapper__forceOpen(aFolder) {
Change by bug 916095,
> +    this.displayedFolder = null;
> +    this.open(aFolder);
> +  },
> +
> +  _renameCompleted: function DBViewWrapper__renameCompleted(aFolder) {
> +    if (aFolder == this.displayedFolder)
> +      this._forceOpen(aFolder);
> +  },

Contention between this request by renameCompleted and clean up process by AnnouncerGoingAway?
By core change, timing of event scheduling, timing of task dispatching, might have been changed.

Comment 88

[WADA:World Anti-bad-Duping Agency]

Bug 916095 was fixed on 2016-11-12. I can't understand reason why problem of this bug didn't occur while creating patch for Bug 916095.
> Bug 916095 - After renaming imap folder, message list is not dislayed only once.

Comment 89

[WADA:World Anti-bad-Duping Agency]

Oh, problem of this bug was referred by Bug 916095 comment #14 with pointing bug 1062408 which was closed as dup of a bug...

Comment 90

[WADA:World Anti-bad-Duping Agency]

Bug 916095 was report for problem in Tb 24, and patch was landed on Tb 52.
- patch of Bug 916095 is absolutely irrelevant to regression window of this bug.
- Far before the regression window, something bad happened after rename of imap folder while message in it is shown in messagepane.

Comment 91

[WADA:World Anti-bad-Duping Agency]

FYI.
At imap folder, when nothing is selected at thread pane and nothing is shown at messagepane(about:blank),
Tb 45: rename imap folder -> error such as exception doesn't occur
       -> message count in folder pane is not shown, nothing is shown in thread pane.
       click other foldser -> ok, click the imap folder again -> ok
Tb 53: rename imap folder -> error such as exception doesn't occur
       -> message count in folder pane is not shown, nothing is shown in thread pane
       -> after a while, message count in folder pane is shown, thread pane is shown, and nothing is selected at thread pane.
       This is perhaps by patch of Bug 916095.
At imap folder, when a mail is selected at thread pane and messagepane is hidden(about:blank),
Tb 53: rename imap folder -> error such as exception doesn't occur
       -> message count in folder pane is not shown, nothing is shown in thread pane
       -> after a while, message count in folder pane is shown, thread pane is shown, but nothing is selected at thread pane

If URL of messagepane = about:blank(and startup page) and no message is loaded in messagepane, problem won't occur.
Problem is generated at messagepane by clearing messagepane after AnnouncerGoingAway due to rename,
or, by clearing messagepane after AnnouncerGoingAway due to rename and by refreshing messagepane after rename completion.

Change like next is needed in ClearMessagePane?
  messagePane.location.href = "about:blank";
  => window.document.getElementById(messagepane).contentDocument.URL = "about:blank" ;

Comment 92

[WADA:World Anti-bad-Duping Agency]

Aha. I could understand why charset in id=messagepane is used in bug 1323377 even when messagepane is hidden, why bug 1324264 occurs.
  ClearMessagePane merely does do messagePane.location.href="about:blank"; only.
This is reason why about:blank is set in document.getElementById(messagepane).contentDocument.URL when startup page was shown and messagepane was hidden.

When exception occurs and problem occurs, header pane in messagepane disappers but message body text is still shown in messagepane.
This indicates that ClearMessagePane is invoked while someone is doing cleanup job of messagepane.
At this stage, messagePane.location is reset and messagePane.location=null or undefined is returned.
And, due to exception, susequent actions won't be executed, then messagepane is broken.
No one sets document.getElementById(messagepane).contentDocument.URL(=about:blank), so messagePane.location=null or undefined  is kept forever, so exception in ClearMessagePane occurs upon each hiding of messagepane after problem happened.

If ClearMessagePane is invoked at this timing, I think URL setting at contentDocument level is needed instead of window object level under contentDocument(DOM window returned by frames of messagepane).

Comment 93

[WADA:World Anti-bad-Duping Agency]

Sorry, following error was returned when document.getElementById(messagepane).contentDocument.URL=about:blank was requestecd.
  Warning: TypeError: setting a property that has only a getter

After exception and problem, following was held in URL of messegapane. (UID=2 in FolderX was shown)
  URL = imap://[e-mail]:993/fetch%3EUID%3E/INBOX/FolderX%3E2
"Doing load of about:blank in onunload event handler after cleanup" may be needed.

Comment 94

[WADA:World Anti-bad-Duping Agency]

window.location was not read only...

Purpose is setting URL="about:blank" instead of changing href part only. There is no need to care about hash, query, ...
So, if messagePane.location is null or undefined, location="about:blank" is sufficient.
>    if (messagePane.location.href != "about:blank")
>        messagePane.location.href = "about:blank";
> 
> => if ( !(messagePane.location) || (messagePane.location.href != "about:blank") )
> =>     messagePane.location = "about:blank";
What is done concurrently is clean up work of messagepane, so changing messagePane.location will do nothing bad.

After exception occurred and problem occurred, when messagePane.location = "about:blank" was set by script,
ClearMessagePane works as expected upon hiding messagepane, folder click etc..
So, problem disappeared.

Comment 95

[WADA:World Anti-bad-Duping Agency]

Above is modified version of first idea.
> if      ( messagePane.location && messagePane.location.href == "about:blank" ) { ; } // no need to do something
> else if ( messagePane.location && messagePane.location.href != "about:blank" )
>     messagePane.location.href = "about:blank";
> else What should be done? What can be done? ==> messagePane.location="about:blank"; was sufficient

Comment 96

[WADA:World Anti-bad-Duping Agency]

Sorry ambigous statement. "floder click" in comment #94 is "other folder click".
Even after ClearMessagePane can work after manual messagePane.location="about:blank" setting, current messagepane is broken(header pane is already removed or hidden). So "folder click of other folder, then click this folder again" is needed.
I think this issue will be resolved by Bug 916095, because folder open is invoked after rename completion by patch of Bug 916095.

Comment 97

[WADA:World Anti-bad-Duping Agency]

Code to force messagePane.location.href=="about:blank" from toolbar button etc.
  window.document.getElementById("messagepane").contentWindow.location = "about:blank" ;

Comment 98

[WADA:World Anti-bad-Duping Agency]

New finding.
Following was rejected by ILLEGAL VALUE in some cases.
> a) window.document.getElementById("messagepane").contentWindow.location = "about:blank" ;
> b) let Win=window.document.getElementById("messagepane").contentWindow; if(win.location){win.location.replace("about:blank");}
In this case, Win.location was shown as [object Location] by DOM Inspector, but Win.location was shown as url string via. toString() by DOM Inspector in other cases.
This indicates that state of messagePane.location depends on timing, and it's impossible to change messagePane.location in some cases.

Comment 99

[WADA:World Anti-bad-Duping Agency]

Any of following was rejected by [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" after problem of this bug occurred in repeated test on Tb 45.
> let Win=window.document.getElementById("messagepane").contentWindow;
> let Exists=(Win.location) was always true, so "if(win.location)" is meaningless.
> (a) if(Win.location.href) { ... } => exception occurs in this if statemernt. toString() is broken?
> (b) if(Win.location) let xxx = Win.location.href;
> (c) if(Win.location) let xxx = Win.location; 
> (d) if(Win.location) let xxx = Win.location.toString();
> (e) if(Win.location) Win.location.href = "about:blank";
> (f) if(Win.location) Win.location = "about:blank";
> (g) if(Win.location) Win.location.replace("about:blank");

When window.document.getElementById("messagepane").loadURI("about:blank",null,"utf-8") is requested, following occurred.
> [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE)
>    [nsIWebNavigation.loadURIWithOptions]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"
>    location: "JS frame :: chrome://global/content/bindings/browser.xml ::
>    loadURIWithFlags :: line 154"  data: no]

browser object(id=messagepane) or LocationObject.toString() or LocationObject was broken when exception occurred in ClearMessagePane due to that LocationObject.href was referred by ClearMessagePane while someone is constructing Location object or messagepane.contentWindow?

In DOM Inspector. above Win.location object was shown as "[object Location]". IIUC, this string of "[object Location]" is obtained by Win.location.toString(). How can DOM Inspector obtain the string of "[object Location]" for the Win.location?
Problem like following?
  window context switch occurred in browser(id=messagepane) because messagepane refresh is requested after loss of folder,
  but Tab of messenger window or browser(id=messagepane) still refers to old window context?

Comment 100

[WADA:World Anti-bad-Duping Agency]

When problem occurs, by DOM Inspector, document.getElementById("messagepane").contentWindow.location is shown as follows. 
> location [object Location]
>   assign      function { [native code] }
>   host        ""
>   hostname    ""
>   reload      function { [native code] }
>   replace     function { [native code] }
>   search      ""
>   toJSON      function { [native code] }
>   toString    function { [native code] }
>   valueOf     function { [native code] }
> No other property is held.

target="about:blank"; etc. at DOM Inspector also fails due to exception. (target = selected property == location)

However,loadContext.associatedWindow.location has full set of properties.
> let Browser=window.document.getElementById("messagepane") ;
> Browser.loadContext.associatedWindow.location content :
> about:blank is shown, all properties are set as expected

Problem is "interfere by ClearMessagePane"? Or already broken before ClearMessagePane accesses location.href?

Even when exception occurred in ClearMessagePane and problem occurred, location="about:blank" sometimes workerd and ClearMessagePane could work without exception after it.
If already broken always before ClearMessagePane accesses location.href, I think problem should be solid and I think setting location="about:blank" from Toolbar button/DOM Inspector should always fail due to exception.
I guess "interfere by ClearMessagePane". (ClearMessagePane is invoked too early)

Comment 101

[WADA:World Anti-bad-Duping Agency]

Funny, while I'm writing above comment, contentWindow.location was set as expected(about:blank).
What I did was following, and did nothing other action at Thunderbird. (writing comment of bug)
 (1) target="about:blank" at DOM Inspector(target==contentWindow.location) (exception is not reported by DOM Inspector)
 (2) At DOM Inspector, viewed loadContext properties, loadContext.associatedWindow properties,
     and loadContext.associatedWindow.location and child peoperties.
 (3) Do nothing on Thunderbird.

contentWindow accessed by Toolbar button != contentWindow accessed by DOM Inspector?
After contentWindow.location="about:blank" at DOM Inspector, old object was removed by Garbage Collector?

Comment 102

[WADA:World Anti-bad-Duping Agency]

Magic/trick was loadContext.associatedWindow.locsation.
  1. Rename imap folder while mail is selected and shown in messagepane -> problem occurs.
     contentWindow.location([object Location]), properties are not initialized properly(no href etc.)
  2. Open DOM Inspector, inspect chrome window(messenger window)
  3. browser(id=messagepane) -> loadContext -> associatedWindow
     click associatedWindow.location(about:blank), all properties of associatedWindow.location
  4. browser(id=messagepane) -> contentWindow -> contentWindow.location
     location=about:blank, all properties of contentWindow.location is set as expected.
This is perhaps reasion why I could set contentWindow.location="about:blank" from Toolbar button some times, but I couldn't set it from Toolbar button almost all cases.

After problem occurs, following script by Toolbar button also repairs broken contentWindow.location, so ClearMessagePane can run.
As known by code, "accessing properties of loadContext, associatedWindow, associatedWindow.location" is sufficient.
> let value;
> let browser = window.document.getElementById("messagepane") ;
> let loadContext = browser.loadContext;
> for(let prop in loadContext){ try{value=loadContext[prop];}catch(e){;} }
> let assocWin = loadContext.assocWin;
> for(let prop in assocWin){ if("location"==prop) continue; try{value=assocWin[prop];}catch(e){;} }
> let LocationURL = assocWin.location.toString() ;
> for(let prop in assocWin.location){ try{ value = assocWin.location[prop] ; }catch(e){;} }

Note:
If assocWin.location and its children was accessed without accessing properties of loadContext and assocWin, exception of NS_ERROR_ILLEGAL_VALUE occurred.
Above code is probably "copy properties from loadContext.associatedWindow to window context which is still used by browser(id=messagepane).
So, cause is perhaps loss of many required properties/objects/functions due to incomplete window context switch at browser(id=messagepane).

Interfere by ClearMessagePane while window context switch is being excuted?
Or window context switch doesn't work well for long time in browser(id=messagepane) under 3pane Tab under messenger window?

Comment 103

[WADA:World Anti-bad-Duping Agency]

Oh, bug 545933 was not fixed yet...
bug 545933 was opened as regression on 2010-02-12 by David :Bienvenu, and following change was checked in by him on 2010-02-23. 
> -  GetMessagePaneFrame().location.href = "about:blank";
> +  try {
> +    GetMessagePaneFrame().location.href = "about:blank";
> +  } catch(ex) {dump("error clearing message pane " + ex + ex.stack);}

Quick history.
1. Exception started to occur in 2010 on GetMessagePaneFrame().location.href = "about:blank";, so it's put in try/catch block.
2. The exception didn't occur so frequently for long time.
3. After it, someone changed code in try block to following, because he excerienced exception.
   > if (messagePane.location.href != "about:blank")
   >     messagePane.location.href = "about:blank";
   It was found useless by this bug, because exception occurs on "if (messagePane.location.href".
   i.e. Fix verification test was never executed upon the change, as usual in B.M.O.
        Code is slightly changed, then bug is closed as FIXED.
4. Change of bug 331376 in mozilla-central was landed between 2014-01-13 and 2014-01-14.
   => Exception started to occur consistently upon imap folder remame/move/delete where message is shown in messagepane.
5. We couldn't be aware of what is problem, even after bug 1062408, this bug, bug 1120361, bug 1193885, bug 1248660, bug 1292170 were reported, despite that regression window was fortunately found by bug 1120361 comment #13 on 2016-10-06.
While re-duping all duped bugs to this bug, I was aware of that bug summary of bug 1062408 and this bug didn't have imap, and was aware of that bugs which has "imap" in bug summary and which clearly states "rename imap folder while message in it is shown at messagepane" in bug summary, was closed as dup. New bugs which has clear STR since initial was hidden by two-step duping.

Sorry but I thought cause was inappropriate code in ClearMessagePane for long time, because it looked for me that problem was resolved once by code change to "if (messagePane.location.href != "about:blank") messagePane.location.href = "about:blank";". If not, why the code change was made in the past?

Exception occurs even on "if(messagePane.location.href)" and messagePane.location always exists.
bug 545933 and this bug is essentially same problem. We could always know that problem had happened after try/catch block by David :Bienvenu.

Comment 104

[WADA:World Anti-bad-Duping Agency]

FYI.

When following was tried after new findings/knowledge on exception of this bug,
  While a message in FolderX is shown at messagepane of messenger window #1,
  delete FolderX at messenger window #2 without selecting FolderX at folder pane of messenger window #2,
(a) if imap folder(with Just mark it as deleted), no exception was opbserved,
(b) but if local mail folder, following exception was observed in Tb 45.
> Error: NS_ERROR_ILLEGAL_VALUE: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIMsgDBHdr.getStringProperty]
> Source File: chrome://messenger/content/mailWindowOverlay.js Line: 2951

When "delete folder", if imap && "Just mark it as deleted", AnnouncerGoingAway, iemRemoved occurs but itemAdded(at Trash) doesn't occur.
If local mail folder, AnnouncerGoingAway, itemRemoved, and itemAdded(at Trash) always occurs.
I think this kind of difference between imap and local mail folder, difference among rename folder and move folder and delete folder, difference between 3pane tab of messenger window and message tab/window, are merely a result of "phenomenon depends on who/when/where detects problem in window context switch at borowser element under Thunderbird window".
I guess that "toString() property(function) relevant functions/objects/properties are lost" is major cause of "always NS_ERROR_ILLEGAL_VALUE".

Comment 105

[WADA:World Anti-bad-Duping Agency]

If messagepane is hidden, problem of this bug won't occur. It may be because ClearMessagePane is not called when no message is shown at messagepane, or because nothing is executed by if(href!="about:blank")href="about:blank" as href=="about:blank" is already set.

If so, and if "window context switch after rename folder" is normally executed when messagepane is hidden, I guess problem is "interfere by ClearMessagePane".
  While contentWindow.location relevant properties are being re-initialized,
  ClearMessagePane accesses contentWindow.location.href by if(href!="about:blank").
Or, if ClearMessagePane is invoked multiple times after rename of imap folder, it may be following.
  By first if(href!="about:blank")href="about:blank", load process is invoked and context swich occurs.
  Upon second if(href!="about:blank") while context switth is in progress, exception occurs, and context switch fails.
Or, it may be simply that Context switch does not occur at browser(id=messagepane) upon imap folder rename, if nothing is shown at messagepane.

Comment 106

[WADA:World Anti-bad-Duping Agency]

There is perhaps hole in above guess.
  When messagepane is manually hidden when a message is already loaded in messagepane,
  contentWindow.location.href is changed to "about:blank" by if(href!="about:blank")href="about:blank".
  However, contentDocument.URI is still kept and messagepane content has data of shwn mail.
  This is reason why "charset in messagepane is used even when messagepane is hiddedn".
This indicates that "document load at messagepane won't occur by if(href!="about:blank")contentWindow.location.href="about:blank" when href!="about:blank".
Problem is that document load/context switch at messagepane won't occur when if(href!="about:blank")contentWindow.location.href="about:blank" is requested upon href!="about:blank"?

Comment 107

[WADA:World Anti-bad-Duping Agency]

Correction on quick history.
Following by bug 545955 on 2010-04-22 was not directly related to exception. It seems a sorting out work of code during feature implementation.
> -    GetMessagePaneFrame().location.href = "about:blank";
> +    let messagePane = GetMessagePaneFrame();
> +    // If we don't do this check, no one else does and we do a non-trivial
> +    // amount of work.  So do the check.
> +    if (messagePane.location.href != "about:blank")
> +      messagePane.location.href = "about:blank";

It's merely change from "if(href!=AB)href=AB;else href=AB;" to "if(href!=AB)href=AB;else do nothing;", but I can't understand added commenet. If href="about:blank" is requested when href="about:blank" is already set, something bad happened? If so, I can not imagine other than "load of about:blank while someone is doing someting on messagepane where about:blank is loaded" and "the load interfered the something".
If meaning of the added comment is "exception occurred", it may be "2nd ClearMessagePane just after 1st ClearMessagePane".
If so, issue in the past may be:
 1st ClearMessagePane when href!="about:blank" -> href="about:blank"
 -> load process of "about:blank" -> window context switch occurs
 -> 2nd ClearMessagePane -> exception of this bug didn't occur in 2010
 -> even though href="about:blank", request href="about:blank"
 -> load of "about:blank" is invoked -> context switch occurs
 -> exception in other modules due to referring to contentWindow.something during context switching

But when messagepane is hidden by drag of separator, ClearMessagePane is called(so exception occurs in this bug), so load of "about:blank" by if(href!=AB)href=AB for "hiding messagepane" should occur when other than "about:blank" is already loaded in messagepane. However, contentDocument.URI is never updated in this case.
Something is different between contentWindow.location.href="about:blank" and loading message in messagepane?

Comment 108

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is Error Console log in Tb 45 when rename was executed.
Because ClearMessagePane is held as window.ClearMessagePane, it was replaced modified module held in Button of Custom Buttions, and timestamp log was written by the modified module. Original code is executed after log by modification.

(A) ClearMessagePane was called twice, first call, the second call after 131 msec.
    This "call 2 times within 1xx msec" was nobserved upon usual folder open.
    This may be a reason of source comment in patch by bug 545955.
    When "hiding messagepane", ClearMessagePane was called only once.
(B) Exception happens at first ClearMessagePane call.
    So, (B-1) contentWindow.location was already broken before the first ClearMessagePane call,
    or  (B-2) contentWindow.location was broken by this referring to contentWindow.location.href, then exception occurred. 
    i.e. Nothing was found by this test about "who broke contentWindow.location".

> IMAP folder rename test with UTC timestamp log in ClearMessagePane.
> window.ClearMessagePane is replaced by modified module held in Button of Custom Buttions.
> timestamp log is written by code added before original code.
> let xxx = contentWindow.location.href is executed in this code part for log.
> 
> (1) IMAP FolderX is selected, a meessage is shown in messagepane
      Rename FolderX to FolderY
> 
> (1-1) First ClearMessagePane call at utc=1482651031136
> 
> Sun Dec 25 2016 16:30:31 GMT+0900 / 1482651031136 : ClearMessagePane , href = 
> [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0 @>code line 1 Function :: ClearMessagePane :: line 105"  data: no]
> 
> Timestamp: 2016/12/25 16:30:31
> Error: error clearing message pane
> Source File: resource:///modules/errUtils.js Line: 34
> 
> Timestamp: 2016/12/25 16:30:31
> Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons- b>utton0@code line 1 Function :: ClearMessagePane :: line 120"  data: no]
> Source File: resource:///modules/errUtils.js Line: 35
> 
> (1-2) Following error was shown
> 
> Timestamp: 2016/12/25 16:30:31
> Warning: ReferenceError: reference to undefined property this.lastFolder.URI
> Source File: resource:///modules/activity/moveCopy.js Line: 285
> 
> (1-3) Second ClearMessagePane call at utc=1482651031267 after 1482651031267 - 1482651031136 = 131 msec
> 
> Sun Dec 25 2016 16:30:31 GMT+0900 / 1482651031267 : ClearMessagePane , href = 
> [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0 @>code line 1 Function :: ClearMessagePane :: line 105"  data: no]
> 
> Timestamp: 2016/12/25 16:30:31
> Error: error clearing message pane
> Source File: resource:///modules/errUtils.js Line: 34
> 
> Timestamp: 2016/12/25 16:30:31
> Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons- b>utton0@code line 1 Function :: ClearMessagePane :: line 120"  data: no]
> Source File: resource:///modules/errUtils.js Line: 35

Comment 109

[WADA:World Anti-bad-Duping Agency]

FYI.

Exception occurs too when messagepane.loadContext.associatedWindow.location.href is referred in ClearMessagePane before accessing contentWindow.location.href by original code.
  ClearMessagePane
    Added code
      log timestamp, let xxx = messagepane.loadContext.associatedWindow.location.href => exception occurs
    Original code
        if (messagePane.location.href != "about:blank")  => exception occurs
          messagePane.location.href = "about:blank";

i.e. Something bad already exists in loadContext.associatedWindow.location before exception occurs in ClearMessagePane.

If code is changed to following as stated in comment #102, exception didn't occur.
  ClearMessagePane
    Added code
      log timestamp, try{let xxx = messagepane.loadContext.associatedWindow.location.href => exception occurs}
      catch(e){ refer all properties of loadContext and loadContext.associatedWindow except associatedWindow.location;
         try{let yyy = messagepane.loadContext.associatedWindow.location.href;}catch(ex){ ... }
         => exception doesn't occur
      }
    Original code
        if (messagePane.location.href != "about:blank")  => exception doesn't occur
          messagePane.location.href = "about:blank";

ClearMessagePane looks victim instead of culprit.

Comment 110

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is event log obtained by folder eventListener, load/unload/select eventLister for messagepane, threadTree, and added code ClearMessagePane.

_hrefAW2=about:blank in log by (3) 1st ClearMessagePane is;
  loadContext.associatedWindow.location.href content after bypass,
  before original ClearMessagePane code requests contentWindow.location.href="about:blank".
So, someone already requested load of "about:blank" before 1st ClearMessagePane call, 
because it was imap mbox uri of shown message before rename folder.
i.e. loadContext.associatedWindow/loadContext.associatedWindow.location is already broken before ClearMessagePane is called.
And, this started to occur from already known regression window.
(a) broken by the change in regression window.
(b) by the change, timing to invoke "other module who requests load of about:blank and relevant modules" was altered.
I guess (b), because if (a), problem should occur in many places including Firefox.
In other cases, exception in dbView is seen, and AnnouncerGoingAway event handler exists in dbView module and msgDatabase module.

(1) Rename imap folder where a message is shown in messagepane

(2) AnnouncerGoingAway is logged by folder listener
>  DateTime=2016/12/25 16:45:17.273 GMT, EventType=AnnouncerGoingAway
>  AnnouncerGoingAway_instigator : [xpconnect wrapped nsIDBChangeAnnouncer]
>    AnnouncerGoingAway_instigator / Property
>    AnnouncerGoingAway_instigator / Function
>      AddListener = function AddListener()
>      NotifyAnnouncerGoingAway = function NotifyAnnouncerGoingAway()
>      NotifyHdrAddedAll = function NotifyHdrAddedAll()
>      NotifyHdrChangeAll = function NotifyHdrChangeAll()
>      NotifyHdrDeletedAll = function NotifyHdrDeletedAll()
>      NotifyJunkScoreChanged = function NotifyJunkScoreChanged()
>      NotifyParentChangedAll = function NotifyParentChangedAll()
>      NotifyReadChanged = function NotifyReadChanged()
>      QueryInterface = function QueryInterface()
>      RemoveListener = function RemoveListener()

(3) 1st ClearMessagePane call is logged by added code to ClearMessagePane.
    Exception occurs by accessing loadContext.associatedWindow.location.href.
    In catch(e) block, properties of loadContext, associatedWindow(except location) is accessed.
    So, referring to contentWindow.location.href by original code
    is normally executed without exception.
> TimeStamp=2016/12/25 16:45:17.274 GMT 1482684317274 : ClearMessagePane , status = ?
> 
>    _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>    _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash_statusEX#1
>    [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0@code line 1 > Function :: ClearMessagePane :: line 138"  data: no]
>    _contentWindowAfterException_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>    _hrefAW2=about:blank

(4) event log by eventListner of id=messegape, id=threadTree. load, unload, select etc. are hooked.
    By contentWindow.location.href="about:blank" in 1st ClearMessagePane call,
    unload occurs in id=messagepane.
> TimeStamp=2016/12/25 16:45:17.276 GMT, window=messenger#2, event.type=unload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/25 16:45:17.298 GMT, window=messenger#2, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/25 16:45:17.316 GMT, window=messenger#2, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/25 16:45:17.317 GMT, window=messenger#2, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree

(5) ItemRemoved, ItemAdded, RenameCompleted are logged by folder listener
>  DateTime=2016/12/25 16:45:17.324 GMT, EventType=Folder_ItemRemoved, item.URI=imap://[e-mail]/INBOX/[Inbox99X/[Inbox99]/FolderZ, parentItem.URI=imap://[e-mail]/INBOX/[Inbox99X/[Inbox99]
>  DateTime=2016/12/25 16:45:17.328 GMT, EventType=Folder_ItemAdded, item.URI=imap://[e-mail]/INBOX/[Inbox99X/[Inbox99]/FolderX, parentItem.URI=imap://[e-mail]/INBOX/[Inbox99X/[Inbox99]
>  DateTime=2016/12/25 16:45:17.355 GMT, EventType=RenameCompleted, FolderURI=imap://[e-mail]/INBOX/[Inbox99X/[Inbox99]/FolderZ

(6) 2nd ClearMessagePane call is logged by added code to ClearMessagePane.
    By bypass in 1st call, exception doesn't occur
> TimeStamp=2016/12/25 16:45:17.424 GMT 1482684317424 : ClearMessagePane , status = ?
> 
>    _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>    _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>    _hrefAW1=about:blank

Comment 111

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is log by added code to ClearMessagePane and by eventListener for messagepane/threadTree.

Gotha.
A big cause of "interfere of window context switch upon load of new location.href" is "messagepane content update while unload is in progress at #document".
Because this is chrome code, and this runs under messenger window instead of under browser(id=messagepane).contentWindow,
code like ClearMessagePane can be invoked and executed regardless of state of browser(id=messagepane).contentWindow and higher #document.
If ordinal HTML Web page, such job is always executed after onload event, and event/code at old window context can not be executed by window context switch.

(1) When imap Inbox is selected and a mail is shown in messagepane, click imap FolderX.

(1-1) 1st ClearMessagePane call. Perhaps for "selection lost at Inbox".
> TimeStamp=2016/12/25 21:30:33.627 GMT ( 1482701433627 ) ClearMessagePane , status = ?
>   Added code writes log.
>   _hrefAW1 = messagepane.loadContext.associatedWindow.location.href content.
>   _hrefCW1 = messagepane.contentWindow.location.href content.
>     _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _hrefAW1=imap://imap.gmail.com:993/fetch%3EUID%3E/INBOX%3E13277
>     _hrefCW1=imap://imap.gmail.com:993/fetch%3EUID%3E/INBOX%3E13277
>   Original code requests messagepane.contentWindow.location.href = "about:blank".

(1-2) 2nd ClearMessagePane call. Perhaps for "selection at FolderX".
  Original code requests messagepane.contentWindow.location.href = "about:blank" again,
  because messagepane.contentWindow.location.href is not "aboput:blank" yet.
> TimeStamp=2016/12/25 21:30:33.632 GMT ( 1482701433632 ) ClearMessagePane , status = ?
>   Added code writes log.
>   _hrefAW1 = messagepane.loadContext.associatedWindow.location.href content.
>   _hrefCW1 = messagepane.contentWindow.location.href content.
>     _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _hrefAW1=imap://imap.gmail.com:993/fetch%3EUID%3E/INBOX%3E13277
>     _hrefCW1=imap://imap.gmail.com:993/fetch%3EUID%3E/INBOX%3E13277
>   Original code requests messagepane.contentWindow.location.href = "about:blank" again,
>   because messagepane.contentWindow.location.href is not "aboput:blank" yet.

(1-3) After it, content of messagepane is re-constructed for newly shown message at FolderX.
  => some elements are loaded to messagepane before unload at higher #document element.
  => event.type=unload occurs at target.nodeName=#document
  => some elements are loaded to messagepane after unload at higher #document element.
  => event.type=load occurs at target.nodeName=#document finaly.
> TimeStamp=2016/12/25 21:30:33.653 GMT, window=messenger#2, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/25 21:30:33.696 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrJunkButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.697 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrTrashButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.697 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrForwardButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.698 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrArchiveButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.698 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.708 GMT, window=messenger#2, event.type=unload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/25 21:30:33.757 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyToSenderButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.757 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyAllButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.758 GMT, window=messenger#2, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyAllButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/25 21:30:33.769 GMT, window=messenger#2, event.type=load, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document

Comment 112

[WADA:World Anti-bad-Duping Agency]

FYI.
Folowing has been found again in this bug.
 change from "location=about:blank" to "if(location.href!=about:blank)location.href=about:blank" in ClearMessagePane was useless.

Comment 113

[WADA:World Anti-bad-Duping Agency]

IIRC and IIUC, "Window context switch upon load of new uri" was introduced to resolve problem like next.
  At old uri, click events etc. are queued.
  By multiple pretty quick form click, by function requests in eventListener and so on, many requests are queued.
  Load of new uri is executed by form request or link request etc.
  => Requests at old uri is executed at new uri.
     If used Javascript function/variable is not available at new uri, many exceptions occur.
     If request at old uri is executable, something bad, including security problem, can easily occur.
  Events are queued in window context, so event scheduling at new uri is avoided by window context switch upon load of new uri.
I believe current code was implemented before this kind of change was made. Change might be done around Firefox 3, but I'm not sure.

Proper solution : write code with respecting following rule.
  request under browser(id=messagepane) should be executed under browser(id=messagepane).

Comment 114

[WADA:World Anti-bad-Duping Agency]

(Off-Topic for bug itself, but relevant to bug report)

I read comment #42 which is a comment for detailed procedure again, and I understood why I couldn't reproduce problem of this bug.
  There is no instruction to select a message and show it in messagepane before rename of imap folder.
I usually do rename of imap folder with imap account selected or right click of non-selected imap folder, in order to avoid excess/useless problems in imap. So, when I tried to reproduce problem of this bug in the past, message in renamed imap folder was not shown in messagepane.
Keywords of this bug :
 (a) rename of imap folder, (b) when the folder is selected at folder pane, (c) when message in it is shown in messagepane.
If these conditions were satisfied, problem was 100% reproducible.
This "100% reproducible" is reason why regression window was successfully discovered by bug 1120361 comment #13 on 2016-10-06(note: not 2015). 
I think one of reasons why some peoples could see problem and reproduce problem but other peoples couldn't reproduce problem was;
  lack of mandatory condition in many descriptions about "Steps to reproduce problem".
  many of them are "partial conditions" and are not "all of mandatory conditions".
And, I couldn't find "imap only problem", "no problem when local mail folder" like comment by quick reading of this bug and dup bugs.
If conditions like following was summarized at good place in erarly stage of this bug, I think developers couild analyze problem in 2014 or first half of 2015, because problem is 100% reproducible since initial of problem(2014-01-14).
 (a) rename of imap folder, (b) when the folder is selected at folder pane, (c) when message in it is shown in messagepane,
 (d) imap only problem,     (e) no problem when local mail folder

Comment 115

[WADA:World Anti-bad-Duping Agency]

Wayne, can you open new bug for problem of this bug and duped bugs, with extracting important information in these bugs, with summaryzing required/mandatory information only, with duping all of this bug and dups of this bug to the new bug?

Comment 116

[WADA:World Anti-bad-Duping Agency]

Attachment: Button script (V1) to replace window.ClearMessagePane for getting timestamp log of ClearMessagePane and doing bypass of exception(bypass is done after exception)

This is button script for button created by Custom Buttons addon.
1. Install Custom Buttons, create button, paste script to 1t.
2. Click button -> window.ClearMessagePane is replaced.
3. After test, restart Tb, please.

Note. Button created by Custom Buttons currently doesn't work on Tb 53.
Test with Tb 52 or before, please.

Comment 117

[WADA:World Anti-bad-Duping Agency]

Issue in window context switch looks to occur by simply requesting messagepane.contentWindow.location="about:blank".
1. imap mail is shown at messagepane
2. Restart DOM Inspector, view messagepane.contentWindow.location and children -> imap mbox url
   Do target="about:blank"; at messagepane.contentWindow.location.href -> still imap mbox url
   Switch to id="messagepanewrapper"(parent), #document(child), and see contentWindow.location.href -> still imap mbox url
3. Close DOM Inspector, restart, Inspect Chome document, view messagepane.contentWindow.location.href -> still imap mbox url
4. Repeat 3. -> still imap mbox url
5. View messagepane.loadContext.associatedWindow, and show location, location.href rows -> about:blank
6. Return to messagepane, messagepane.contentDocument, and show location, location.href part -> "about:blank" is shown
7. At messenger window, click other mail in imap folder -> imap mail is shown in messagepane
8. At DOM Inspector, view messagepane.contentDocument.location -> imap url
   view messagepane.loadContext.associatedWindow.location -> about:blank
   view messagepane.contentDocument.location again -> about:blank

Current messagepane.contentDocument.location.href=about:blank is executed under messenger window context.
All should be executed under messegapane.contentWindow context as done in HTML of Web document under Web Browser?
document load is needed instead of location.href=url?

Anyway, "update of header pane etc. before unload at #document upon message display at messagepane" is wrong.
"Calling ClearMessagePane who has logic of location.href=about:blank 2 times within 100msec" may be bad behavior, because location.href=url == load of the url and load of a url takes a while.
2nd call of ClearMessagePane should wait for completion of location.href=about:blank(==load of url) requested by 1st ClearMessagePane.

Comment 118

[WADA:World Anti-bad-Duping Agency]

I've found what is regression.
trunk 2014-01-14 build : exception occurs as expected, and my button script works as expected.
trunk 2014-01-13 build : exception doesn't occur as expected,
                         but, if my button script replaced window.ClearMessagePane, nothing occurred by folder switch etc.
                         By my button script, Tb was broken.
                         => Checked by DOM Inspector => browser(id=messagepane).loadContext is not found.

A big change in mozilla-central looks landed on 2014-01-14. Perhaps bug 957427.

Comment 119

[WADA:World Anti-bad-Duping Agency]

New quick history of ClearMessagePane.

(1) bug 545933 was opened as regression on 2010-02-12 by David :Bienvenu,
    and following change was checked in by him on 2010-02-23 to hook exception. 
> -  GetMessagePaneFrame().location.href = "about:blank";
> +  try {
> +    GetMessagePaneFrame().location.href = "about:blank";
> +  } catch(ex) {dump("error clearing message pane " + ex + ex.stack);}
Issue may be "two concecutive location.href=about:blank within 100 msec".

(2) Following change was made by bug 545955 on 2010-04-22 during feature implementation.
>    try {
> -    GetMessagePaneFrame().location.href = "about:blank";
> +    let messagePane = GetMessagePaneFrame();
> +    // If we don't do this check, no one else does and we do a non-trivial
> +    // amount of work.  So do the check.
> +    if (messagePane.location.href != "about:blank")
> +      messagePane.location.href = "about:blank";
>    } catch(ex) {dump("error clearing message pane " + ex + ex.stack);}
If "load of about:blank by first ClearMessagePane" completes within 100 msec and location.href is immediately changed to about:blank,"double request of location.href=about:blank within 100 msec" is successfully avoided by this change.

(3) loadContext was exposed by bug 957427 on 2014-01-14, and exception on "if (messagePane.location.href" started to occur consistently.

Why IMAP only problem?
Before "two concecutive ClearMessagePane requests within 100 msec", location.href=about:blank is requested when IMAP?

Comment 120

[WADA:World Anti-bad-Duping Agency]

FYI.

"Window context swtich" what I call is change by Bug 393762. In this erra, it looks called ScriptHandlingObject, ScriptGlobalObject etc. This was done to resolve problem like bug 252542.
It looks that loadContext was implemented for Private Browsing. It seems exposed to support Remote Browser and many components well.
Developer said "I don't like exposing it more than we already do." in bug 957427.
If so, please don't expose loadContext to Thunderbird. :-)

Comment 121

[WADA:World Anti-bad-Duping Agency]

A new finding.

Following is timestamp log by added code to ClearMewssagePane when rename of local mail folder is executed.
 _hrefAW1 is content of loadContext.associatedWindow.location.href when ClearMewssagePane is called.
 _hrefCW1 is content of contentWindow.location.href when ClearMewssagePane is called.
If local mail folder, "unload/load by location.href=about:blank" completes within 227 msec and about:blank is set in location.href after it, so location.href==about:blank is returned upon 2nd ClearMessagePane call.

> TimeStamp=2016/12/26 14:02:59.750 GMT ( 1482760979750 ) ClearMessagePane , status = ?
>   timestamp log by added code
>     _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _hrefAW1=mailbox:///C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/q8yh6xh8.Release/Mail/Local%20Folders/Test.sbd/X1.sbd/ABCX?number=12
>     _hrefCW1=mailbox:///C:/Users/Wada/AppData/Roaming/Thunderbird/Profiles/q8yh6xh8.Release/Mail/Local%20Folders/Test.sbd/X1.sbd/ABCX?number=12
>   original code is executed
>     contentWindow.location.href=about:blank is requested because location.href is mbox url.
> 
> TimeStamp=2016/12/26 14:02:59.977 GMT ( 1482760979977 ) ClearMessagePane , status = ?
>   timestamp log by added code
>     _contentWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _associatedWindow_assign_replace_reload_toString_valueOf_href_origin_protocol_host_hostname_port_pathname_search_hash
>     _hrefAW1=about:blank
>     _hrefCW1=about:blank
>   original code is executed
>     contentWindow,location.href is NOT requested, because href=about:blank is already set

When IMAP folder rename case, imap mbox url is always returned to both 1st ClearMessagePane call and 2nd ClearMessagePane call, so location.href=about:blank is requested 2 times consecutively by ClearMessagePane.
It's probably that "unload of IMAP URL by location.href=about:blank" takes longer than "unload of local mail folder URL".
This is perhaps a reason why problem occurs in IMAP folder rename only.
I think phenomenon is as follows.
(1) "something bad in loadContext" is generated due to "interfere of loadContext"
     by bad Thunderbird behavior such as "consecutive location.href=about:blank requests",
     "header pane element load while unload at higher #document is in progress".
(2) The "something bad in loadContext" was exposed by another bad behavior in Thunderbird
    when rename of IMAP folder is executed while message is shown in messagepane.
A bad behavior in this bug's case:
  location.href=URL == unload of previous document and load of new document of the new URL.
  But location.href is treated as-if merely a string property of an object in Thunderbird code.
  Following comment in patch of bug 545955 may be indicating it.
> +    // If we don't do this check, no one else does and we do a non-trivial
> +    // amount of work.  So do the check.
    
loadContext was originally implemented for Private Browsing.
I think "Don't enable loadContext in XUL browser/window" is a possible solution in Thunderbird.
  XUL browser/window in mailer != Web browser window for Web pages.
  Loss of Private Browsing capability by disabling loadContext in XUL browser/window of mailer
    << ... << Gain by disabling loadContext in XUL browser/window of mailer

Comment 122

[Wayne Mery (:wsmwk)]

(In reply to WADA:World Anti-bad-Duping Agency from comment #115)
> Wayne, can you open new bug for problem of this bug and duped bugs, with
> extracting important information in these bugs, with summaryzing
> required/mandatory information only, with duping all of this bug and dups of
> this bug to the new bug?

You understand the issues far better than I do, so please file new bugs as needed.  If there are multiple issues then one new bug report per issue (or reopen an existing one), and the regression bug properly identified in dependencies. 

ALSO, we need patches with automated tests in this area (or manual tests), so we don't get in this situation again.

Comment 123

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #122)

It's penalty. Who hidden important information should do recovery job from it. :-)

Before open new bug, "another bad behavior" of following in previous comment should be found in this bug in order for crisp new bug.
> (2) The "something bad in loadContext" was exposed by another bad behavior in Thunderbird
Many comments for problem analysis due to trial and error is better avoided in new bug. New bug should be bug for implementing solution.

When exception occurred in 1st ClearMessagePane call, "about:blank" was already held in loadContext.associatedWindow.location.href.
I think (a) instead of (b).
  (a) getter of contentWindow.location -> loadContext.associatedWindow.location
  (b) getter of loadContext.associatedWindow.location -> contentWindow.location
It indicates that someone already requested location/location.href=about:blank or requested load of about:blank before the exception in 1st ClearMessagePane call.
"When/how/by whom such requet was issued" should be discovered in this lo---ng bug : more than 100 comments, more than 2 years from bug open, 3 years from regression started to occur...

Comment 124

[WADA:World Anti-bad-Duping Agency]

New finding and questions.

I added code to check function caller chain to see callers of ClearMessagePane.

(1) Open IMAP FolderX, then message is shown in messagepane.
    Why "two consecutive ClearMessagePane calls within 8 msec" in needed?

> TimeStamp=2016/12/26 18:59:00.158 GMT ( 1482778740158 ) ClearMessagePane ,
>   ClearMessagePane <- MessageDisplayWidget_clearDisplay
>   <- MessageDisplayWidget_onDestroyingView <- FolderDisplayWidget_onDestroyingView
>   <- DBViewWrapper_close <- DBViewWrapper_open <- FolderDisplayWidget_show
>   <- FolderPaneSelectionChange <- onselect <- onxblmousedown
> 
> TimeStamp=2016/12/26 18:59:00.166 GMT ( 1482778740166 ) ClearMessagePane ,
>   ClearMessagePane <- MessageDisplayWidget_clearDisplay <- summarizeFolder
>   <- MessageDisplayWidget_showSummary <- MessageDisplayWidget_onSelectedMessagesChanged
>   <- FolderDisplayWidget_summarizeSelection

(2) Rename IMAP FolderX to FolderY
    Why following is needed?
      Two consecutive ClearMessagePane calls within 17 msec.
      Two consecutive ClearMessagePane calls from two different modules.

> TimeStamp=2016/12/26 19:00:22.516 GMT ( 1482778822516 ) ClearMessagePane ,
>   ClearMessagePane <- MessageDisplayWidget_clearDisplay <- summarizeFolder
>   <- MessageDisplayWidget_showSummary <- MessageDisplayWidget_onSelectedMessagesChanged
>   <- FolderDisplayWidget_summarizeSelection
> 
> TimeStamp=2016/12/26 19:00:22.633 GMT ( 1482778822633 ) ClearMessagePane ,
>   ClearMessagePane <- MessageDisplayWidget_clearDisplay <- summarizeFolder
>   <- MessageDisplayWidget_showSummary <- MessageDisplayWidget__wrapShowSummary

Comment 125

[WADA:World Anti-bad-Duping Agency]

New questions.

Following is eventListener log(beforeunload is added, because this bug is relevant to load/unload).

(1) imap folder switch by folder click at folder pane

beforeunload was invoked 3 times. Why? By whom? When? How?
This is probably relevant to "broken contentWindow.location/location.href" phenomenon of this bug.

> TimeStamp=2016/12/26 21:28:21.504 GMT, event.type=beforeunload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:28:21.510 GMT, event.type=beforeunload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:28:21.525 GMT, event.type=beforeunload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:28:21.531 GMT, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/26 21:28:21.572 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrJunkButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.573 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrTrashButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.573 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrForwardButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.574 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrArchiveButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.574 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.581 GMT, event.type=unload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:28:21.642 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyToSenderButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.644 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyAllButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.645 GMT, event.type=load, currentTarget.id=msgHeaderView, currentTarget.nodeName=hbox, target.id=hdrReplyAllButton, target.nodeName=toolbarbutton
> TimeStamp=2016/12/26 21:28:21.648 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.649 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.649 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.650 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.650 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.651 GMT, event.type=load, currentTarget.id=attachmentView, currentTarget.nodeName=vbox, target.nodeName=attachmentitem
> TimeStamp=2016/12/26 21:28:21.664 GMT, event.type=load, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document

(1) rename imap folder -> exception in added code
    -> exception in ClearMessagePane is bypassed by accessing loadContext/associatedWindow.

select event is seen 3 times at threadTree after unload at #document.
Requests by dbView?

> TimeStamp=2016/12/26 21:38:07.102 GMT, window=messenger#1, event.type=beforeunload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:38:07.102 GMT, window=messenger#1, event.type=unload, currentTarget.id=messagepane, currentTarget.nodeName=browser, target.nodeName=#document
> TimeStamp=2016/12/26 21:38:07.122 GMT, window=messenger#1, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/26 21:38:07.144 GMT, window=messenger#1, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree
> TimeStamp=2016/12/26 21:38:07.144 GMT, window=messenger#1, event.type=select, currentTarget.id=threadTree, currentTarget.nodeName=tree, target.id=threadTree, target.nodeName=tree

Comment 126

[WADA:World Anti-bad-Duping Agency]

These findings/questions are New Year's present to developrs.
To developers, please answer my questions in new year holidays :-)

Comment 127

[WADA:World Anti-bad-Duping Agency]

Stack trace is better than Function.caller, because line number is shown and no "deprecated caller usage" warning.
See this stack trace instead of comment #124, please.

(1) imap folder click and folder switch 

> TimeStamp=2016/12/27 00:06:10.540 GMT ( 1482797170540 ) ClearMessagePane , status = 
> ClearMessagePane@chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0@code line 1 > Function:126:44
> MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:153:5
> MessageDisplayWidget_onDestroyingView@chrome://messenger/content/messageDisplay.js:172:7
> FolderDisplayWidget_onDestroyingView@chrome://messenger/content/folderDisplay.js:1020:5
> DBViewWrapper_close@resource://gre/modules/dbViewWrapper.js:720:7
> DBViewWrapper_open@resource://gre/modules/dbViewWrapper.js:768:5
> FolderDisplayWidget_show@chrome://messenger/content/folderDisplay.js:804:9
> FolderPaneSelectionChange@chrome://messenger/content/commandglue.js:352:3
> onselect@chrome://messenger/content/messenger.xul:1:1
> onxblmousedown@chrome://global/content/bindings/tree.xml:1087:14
>  
> TimeStamp=2016/12/27 00:06:10.546 GMT ( 1482797170546 ) ClearMessagePane , status = 
> ClearMessagePane@chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0@code line 1 > Function:126:44
> MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:153:5
> summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:3
> MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.js:344:7
> MessageDisplayWidget_onSelectedMessagesChanged@chrome://messenger/content/messageDisplay.js:245:12
> FolderDisplayWidget_summarizeSelection@chrome://messenger/content/folderDisplay.js:1423:12
> DBViewWrapper__createView@resource://gre/modules/dbViewWrapper.js:1065:1
> DBViewWrapper__applyViewChanges@resource://gre/modules/dbViewWrapper.js:1374:19
> DBViewWrapper__enterFolder@resource://gre/modules/dbViewWrapper.js:1142:5
> DBViewWrapper_open@resource://gre/modules/dbViewWrapper.js:801:7
> FolderDisplayWidget_show@chrome://messenger/content/folderDisplay.js:804:9
> FolderPaneSelectionChange@chrome://messenger/content/commandglue.js:352:3
> onselect@chrome://messenger/content/messenger.xul:1:1
> onxblmousedown@chrome://global/content/bindings/tree.xml:1087:14

(2) imap folder rename(exception occurs in added code, bypassed by added code)

> TimeStamp=2016/12/27 00:07:31.737 GMT ( 1482797251737 ) ClearMessagePane , status = 
> ClearMessagePane@chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0@code line 1 > Function:126:44
> MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:153:5
> summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:3
> MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.js:344:7
> MessageDisplayWidget_onSelectedMessagesChanged@chrome://messenger/content/messageDisplay.js:245:12
> FolderDisplayWidget_summarizeSelection@chrome://messenger/content/folderDisplay.js:1423:12
> ThreadPaneSelectionChanged@chrome://messenger/content/threadPane.js:387:3
> onselect@chrome://messenger/content/messenger.xul:1:1
> 
> TimeStamp=2016/12/27 00:07:31.901 GMT ( 1482797251901 ) ClearMessagePane , status = 
> ClearMessagePane@chrome://custombuttons-context/content/button.js?windowId=Thunderbird&id=custombuttons-button0@code line 1 > Function:126:44
> MessageDisplayWidget_clearDisplay@chrome://messenger/content/messageDisplay.js:153:5
> summarizeFolder@chrome://messenger/content/selectionsummaries.js:100:3
> MessageDisplayWidget_showSummary@chrome://messenger/content/messageDisplay.js:344:7
> MessageDisplayWidget__wrapShowSummary@chrome://messenger/content/messageDisplay.js:359:5

Comment 128

[WADA:World Anti-bad-Duping Agency]

Stack trace was better.

IMAP folder switch from FolderX(looser) to FolderY(winner) case:
It looks similar job for clean up is invoked for both FolderX(looser) and FolderY(winner) at same time.
From perspective of well formed HTML and script, following is good manner.
  Start unload process for FolderX(looser), wait for unload completion, and start load prosess for FolderY(winner).

IMAP folder rename from FolderX(looser) to FolderY(winner) case:
Two functions tries to do similar clean up job for FolderX(looser), and for FolderY(winner) after 100-200 msec.
Currently, even if exception is bypassed, nothing is shown at thread pane, header pane is hidden, attachment pane is hidden, and messagepoane is kept with mixed body data of three messages(this is perhaps 3 select in my test. 3 mails which have attachment?).
"Click other folder, then click again" is needed as reported to bug 916095.
To bypass this issue, we have to wait for Tb 52 on which patch of bug 916095 is landed.
Something was broken by summarizeFolder?

From perspective of well formed HTML and script, following is good manner.
  Start unload/clean up process for FolderX(looser), wait for unload completion, and start load prosess for FolderY(winner).
For smooth transission from URL-X state to URL-Y state, JavaScriptSocpe, loadContext like one was implemented, but it was interfered by XUL elements and code at outside of them...

Comment 129

[WADA:World Anti-bad-Duping Agency]

About loadContext.

id="messagepane" is browser element(similar to iframe under it) which is for providing a browser window environment(browser.contentWindow is "window object for loaded HTML, used script" and browser.contentDocument is "window.document for HTML/script).
This "browser element" is also used in "Trouble shhoting Information" tab where loaded object is HTML page like a browser windoe/tab for Web page.
browser.loadContext is associated to the browser.contentWindow for a Web page.

This is reason why loadContext suddenly appeared by "exposing loadContext on 2014-01-14".
"Why browser element" is HTML is utilized for mail display and HTML mail is shown there.
In mail display, Javascript is already disabled and form submit with post is perhaps already disabled and link click/form-get="pass the url to external browser" != "load of new url at there".
I think loadContext is not needed in browser(id=messagepane).
boweser element for id=messenger is merely an alternative/convinient/powerful box element.

As loadContext was implemented for Private Browsing, it, I think its use is all up to "browser element designer".
Is there way to disable loadContext in browser element for id=messenger?

It may be due to getInterface(Components.interfaces.nsIDOMWindow) use instead of new nsILoadContext interface use.
> https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Limitations_of_chrome_scripts#Observers_in_the_chrome_process
> https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Tabbed_browser
> https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Tabbed_browser#Getting_the_browser_that_fires_the_http-on-modify-request_notification_%28example_code_updated_for_loadContext%29
If so, transfer to nsILoadContext interface may be a proper solution because it's XPCOM object.
(I guess it's reason why "refer all properties of loadContext/associatedWindow" can be a bypass of exception.)

Comment 130

[WADA:World Anti-bad-Duping Agency]

Attachment: Event log when imap folder rename, obtained by added code to ClearMessagePane, other eventListerners for folder event and event on messagepane/threadPane(bypass is done before location.href access)

New finding.

Attached is event log of (1-1).
1st ClearMessagePane call is invoked by summarizeFolder just after 1 msec from 
AnnouncerGoingAway produced by "rename imap folder".
Stacktrace part in log is written by (new Error()).stack by logger module in button script.
Some modules held in window are copied to button script and modified, and replaced by it for trace logging. 

(1) Following was observed in tests.

(1-1) Rename imap folder where message is shown in messagepane
modified ClearMessagePane #1
  Original code does location.href=about:blank -> exception
  In catch block, access properties of looadContext and associatedWindow,
  and do "if(location.href!=about:blank)location.href=about:blank"
  -> No error occurs after it.
     All other features works after it.
  -> By other eventListener, unload event is logged while added code of ClearMessagePane 
     is accessing properties of looadContext and associatedWindow.
     This was produced by location.href=about:blank of ClearMessagePane #1, as known by (2). 

(1-2) Rename imap folder where message is shown in messagepane
modified ClearMessagePane #2
  Does do nothing on location.href, never touch location.href or others
  -> exception doesn't occur, but after it,
     header pane, messagepane, attachment pane was refereshed by any one.
     I could understand meaning of following comment by bug 545955.
> +    // If we don't do this check, no one else does and we do a non-trivial
> +    // amount of work.  So do the check.
>      if(location.href!=about:blank) location.href=about:blank
  -> if messengepane.contentWindow.location/location.href is touched by button script,
     exception occurs too, as expected.
  -> unload event is not logged by other event listener.
     So, the unload event 
     was produced by location.href=about:blank of ClearMessagePane #1.

(1-3) Rename imap folder where message is shown in messagepane
modified ClearMessagePane #3
  Before original code accesses location.href,
  always access properties of loadContext.associatedWindow only without access loadContex
  -> "if(location.href!=about:blank) location.href=about:blank" workes normally.
  However, after it, error "dbView.something is not found" is reported,
  and header pane, messagepane, attachment pane is not update.
  
(1-4) Rename imap folder where message is shown in messagepane
modified ClearMessagePane #4
  Before original code accesses location.href,
  allways access properties of loadContext and loadContext.associatedWindow, as done by (1).
  -> "if(location.href!=about:blank) location.href=about:blank" workes normally.
  -> Header pane, messagepane, attachment pane etc. are updated normall, as done in (1).

My conclusion.
(A) ClearMessagePane is merely a victim.
    loadContex/associatedWindow/contentWindow is already broken.
    ClearMessagePane merely accesses broken contentWindow.location.href first,
    according to call by summarizeFolder just after 1 msec from AnnouncerGoingAway.
(B) Because summarizeFolder and his owner is invoked just after 1 msec from AnnouncerGoingAway,
    activities in FolderDisplayWidget_summarizeSelection, MessageDisplayWidget_showSummary,
    summarizeFolder just after AnnouncerGoingAway
    may be culprit of broken loadContext/associatedWindow.
(C) Because imap only problem, it may be produced by cuncurrent action by  summarizeFolder code and imap code.
summarizeFolder looks to care about collapse/expand of thread like event only.
It doesn't look to care about "folder loss, no msgDBHdr, no threadpane entry" case.

Anyway, bypass code was found. "Code like following just before try/catch block" is currently known simplest/easiest bypass of exception problem.
> let browser=window.document.getElementById("messagepane");
> let loadContext=browser.loadContext;
> let accociatedWindow=loadContext.accociatedWindow ;
> let contentWindow=browser.contentWindow ;
> Wins=new Array();
> Wins[0]=loadContext;
> Wins[1]=accociatedWindow;
> for(let nn=0;nn<Wins.length;nn++)
> {
>     let DOMwin=Wins[nn];
>     for(let prop in DOMwin)
>     {
>        if("location"==prop) continue;
>        try{let value=DOMwin[prop];}catch(e){;}
>     }
> }

I think "why this kind of bypass works" is that cause is lack of correct queryInterfaces, but I'm not sure.

Comment 131

[WADA:World Anti-bad-Duping Agency]

My guess.
When URL of browser(id=messagepane) is changed, context swich occurs. So, events queued at old context are discarded at browser(id=messagepane) with new context, and context is switched to one for new URI.
Chrome code works under context of messenger window. A possible solution may be "utilizing singleton module(jsm, JavaScript modules)". Because singleton module is executed under different context(no window context/scope), it may not be affected by context/scope switch at browser(id=messegepane).

Comment 132

[WADA:World Anti-bad-Duping Agency]

Another new finding.

While I tested my code added to ClearMessagePane, I saw following exception sometimes, but I didn't care about it.
However, when I did next, I was aware of following error.
1. Start Thunderbird 45. Inbox is selected. With do nothing, right click FolderX, open new messenger window #2.
2. At messenger window #2, with do nothing, button click and change ClearMessagePane module, and clear Error Console.
3. Rensame FolderX to FolderY
-> Following error was reported first to Error Console.
> Timestamp: 2016/12/30 1:51:13
> Warning: ReferenceError: reference to undefined property this.lastFolder.URI
> Source File: resource:///modules/activity/moveCopy.js Line: 285

This error occurs at following code which is folderRenamed event handler.
> folderRenamed: function(aOrigFolder, aNewFolder) {
>   this.log.info("in folderRenamed, aOrigFolder = "+ aOrigFolder.prettiestName+", aNewFolder = "+
>            aNewFolder.prettiestName);
> 
>   let displayText;
>   let statusText = aNewFolder.server.prettyName;
> 
>   // Display a different message depending on whether we moved the folder
>   // to the trash or actually renamed the folder.
>   if (aNewFolder.isSpecialFolder(nsMsgFolderFlags.Trash, true))
>   {
>     displayText = this.getString("movedFolderToTrash");
>     displayText = displayText.replace("#1", aOrigFolder.prettiestName);
>   }
>   else
>   {
>     displayText = this.getString("renamedFolder");
>     displayText = displayText.replace("#1", aOrigFolder.prettiestName);
>     displayText = displayText.replace("#2", aNewFolder.prettiestName);
>   }
> 
>   // When renaming a folder, a delete event is always fired first
> 
> *** Reference error occurs here *** 
>   if (this.lastFolder.URI == aOrigFolder.URI)
>     this.activityMgr.removeActivity(this.lastFolder.event);
> 
>   // create an activity event
>   let event = new nsActEvent(displayText,
>                              aOrigFolder.server,
>                              statusText,
>                              Date.now(),  // start time
>                              Date.now()); // completion time
> 
>   event.addSubject(aOrigFolder);
>   event.addSubject(aNewFolder);
> 
>   this.activityMgr.addActivity(event);
> },

Rensame folder then AnnoucingGoaWay on previously opened foilder, so lastFolder already disappeared.
After this Reference error, same Javascript error in same module may not be reported again to reduce exception log. 
I guess a reason of "threadPane is not refreshed after rename, messagepane is kept with old mail body data" is this excerption in folderRenamed event handler.

Comment 133

[WADA:World Anti-bad-Duping Agency]

Above is probably a reason why change on _renameCompleted: in dbView by bug 916095, which is referred in comment #87, was needed.

Comment 134

[WADA:World Anti-bad-Duping Agency]

"Quick summary of problem at end of 2016" after bypassing exception by property check of loadContext and accociatedWindow.

(1) After rename of IMAP folder, and after bypassing exception in ClearMessagePane, following occurs.
(1-a) message count in folder pane is blank,
(1-b) nothing is shown in threadPane,
(1-c) body of previously shown message is kept in messagepane, 
      (perhaps because "URL change request of location.href=about:blank by 1st ClearMessagePane call" is interfered)
      and header pane/attachment pane is still hidden(because ClearMessagePane did it).

A cause of (1-a)/(1-b) is probably relevant to following error which was observed when new message pane is opened, when rename is executed etc.
> Warning: ReferenceError: reference to undefined property this.treeBoxObject.columns
> Source File: chrome://global/content/bindings/tree.xml Line: 50
Because previously selected folder at folder pane doesn't exist or lost by rename, treeBoxObject for it doesn't exist.
This is perhaps reason why folder is not opened after rename upon renamecompleted folder event.
This issue was worked around by showing "Folder Property".
"Folder click at folder pane" does do nothing, because folder is already shown at folder pane.
"Folder property" != !"Folder open by click", and folder property executes "open with reparse", and threadPane is refreshed after it.
This can be called "manual operation version of patch by bug 916095". 

Cause of (1-c) is that nothing is shown at threadPane then no dbView or no selected message in null dbView.
When threadPane is shown, because last selection at threadPane is not available, nothing is done on messagepane etc.
But because threadPane/dbView is now available by "Folder Properties", select message at threadPane is possible, and header pane/ messagepane are refreshed by selecting message.

(2) About cause of exception upon accessing location.href.

When AnnouncingGoAway is notified, someone perhaps requests something on messagepane and unload(may be by load of new URL request).
And summarizeFolder and relevant code invokes just after 1 msec of the AnnouncingGoAway event.

If location.href is accessed by ClearMessagePane while unload process just started, exception occurs by referring location.href, and once exception occurs, unload process/context switch is interfered, and broken state continues until loadContext/associatedwWindow is accessed by someone.

While added code is doing access of all properties of loadContext/associatedwWindow to bypass exception(took approximately 3 msec)
msec), beforeunload event and unload event was notified to eventListener, and exception occurred in unload/load eventLister when eventListener accessed messagepane.currentURL, messagepane.documentURI.
Because beforeunload/unload, messagepane.contentWindow scope/context is for old URIX of "URI change request from URLX to URLY".
It seems that "load process of URLY in unload URLX/load URLY request" is lost due to interfere by chrome code while browser(id=messagepane) is processing "unload URLX/load URLY request by someone", because load event was not notified to eventListner of browser element(id=messagepane).

I think cause of exception is "access/change browser's unload/load relevant properties such as location, documentURI, currentURI while just after unload/load is requested without waiting for load completion".
And who actually did it was chrome code of summarizeFolder and his family.
I can't think who initiated "unload(and load) at messagepane upon AnnoucingGoAway" is summarizeFolder and his family, because 1st request by them seems 1st call of ClearMessagePane where exception occurs first.
Who initiated "unload(and load) at messagepane upon AnnoucingGoAway"?

I think AnnouncingGoAway is relatively new event for Mozilla mailnews/Thunderbird code.
I think that following  is not cared about well.
- state of "msgFolder, msgDatabase, dbView etc. are lost by rename"
- fact of "what folder is created by rename can not be known until renamecompleted event is notified"
Any event driven code can not know about "rename and state after rename" while rename and after jobs is in progress.
Who knows about it is UI code who accepted "rename from FolderX to FolderY" only.
Process like next may be needed.
- Hold request of "rename from FolderX to FolderY" at somewhere, and each event driven modules referrs to it.
- Hold request of "url change from urlX to urlY" at somewhere, and subsequesnt process waits for load completion.

Comment 135

[WADA:World Anti-bad-Duping Agency]

Attachment: button script(v2) to add code for "bypass exception in ClearMessagePane"(bypass is done before location.href access)

1. Install Custom Buttons addon, add button, paste script.
2. Restart Thunderbird 45, open Error Console.
3. Open new messenger window #X.
   At messenger window #X, click button
   -> modified modules are stored in window.xxx, and eventListener is added.
   Because eventListener is added, "click button" should be executed only once.
4. Do folder switch, message display etc., and clear Error Console,
   and rename imap folder where message in it is shown at message pane.

Because modified modules are Tb 45 code, and because button of Custom Buttons didn't work on Tb 52 and Tb 53, please test on Tb 45 only.
What was done by added code is merely followin;
ClearMessagePane :
- Hold flag/count for "location.href change requested, but load event is not notified" in window.XXX object.
- If flag is on, don't request location.href change, and add 1 to count.
- In eventLister for "load", clear flag and reset count to 0.
- Before access to location.href in ClearMessagePane,
  access all properties of loadContext and associatedWindow.
Change of "if(flag) skip location.href access/change" part was added to loadStartPage too, because loadStartPage did "location.href=start page or about:blank".
All other Thunderbird modules are copied and modified only to log of "module is invoked" to see "what is done by whom at when".

After it, exception was observed only when next event.

While ClearMessagePane is accessing all properties of loadContext and associatedWindow upon first call of ClearMessagePane just after AnnouncingGoAway by rename,
beforeunload/unload event is notified to eventListner and eventListner referred to messagepane.documentURL, messagepane.currentURL etc. for logging.

Needless to say, because of beforeunload/unload event, "window context/scope when eventListener is invoked" is one for urlX in "url change from urlX to urlY".

Comment 136

[WADA:World Anti-bad-Duping Agency]

FYI.
I've opened bug 1326371 and bug 1326375 for loadStartPage.

Comment 137

[WADA:World Anti-bad-Duping Agency]

Many my guesses was wrong, although some were cotrrect..

It was too early accerss to location.href due to too early call of ClearMessagePane by summarizeFolder.

> ClearMessagePane code change :
>    Never request location.href=about:blank,
>    Merely waste time by accessing many properties of big objects.
> 
>    Case-0                      Case-1                      Case-2                   
> 
>   <--- after 1 msec from AnnouncerGoingAway, ClearMessagePane is called by summarizeFolder ----->
> 
>    access all properties of    access all properties of     access all properties of
>      browser
>      loadContext                 loadContext
>      associatedWindow            associatedWindow             associatedWindow  only
> 
>                                                             in this test, documentURI was accessed
>                                                             => exception occurred by it.
>                                                                and caught by catch.
>                                                             => access of all properties of object
>                                                                was not done in test.
> 
>                                                           takes 1 msec
>                                                           ends before unload
> 
>                                                           => if location.href is referred before unload,
>                                                              exception occurs too.
>                                                           => loadContext switch is interferred, then broken
> 
>   <--- beforeunload and unload always occurs here in Case-0/Case-1   -------------------------------->
>   <---      despite that ClearMessagePane never access location.href -------------------------------->
>   <--- i.e. someone(perhaps summarizeFolder or his family requested url change. --------------------->
>   <---      request is probably "load about:blank" -------------------------------------------------->
> 
>                                                           because loadContext etc. is broken by exception,
>                                                           beforeunload/unload didn't occur,
>                                                           and load also didn't occur.
>                                                           summarizeFolder looks to wait for about:blank
> .                                                         forever.
>                                takes 3-4msec
>                                ends 1 msec after unload
>                                documentURI was about:blank
>    takes 13 msec
>    ends 10 msec after unload   
>    documentURI was about:blank
> 
>    after it, never request     after it, never request     after it, never request
>      location.href=about:blank   location.href=about:blank   location.href=about:blank
>      
>    control is retutned        control is retutned          control is retutned
>      after 13 msec              after 3-4 msec               after 1 msec    
>      
>   <------------------------ ClearMessagePane ends ---------------------------------------------->
> 
>    Folder Properties        Folder Properties             Even after thred pane id shown,
>     -> thread pane shown     -> thread pane shown         when messasge is selected,
>    message click]           message click                 nothing is shown in messagepane
>     -> message is shown      -> message is shown

Exception looks timing problem.
After rename, summarizeFolder or someone looks to request load of about:blank.
So, if "1st call of ClearMessagePane just after AnnouncerGoingAway" is not executed,
I think exception problem won't occur.

In Case-0 and Case-1, problem won't occur even though ClearMessagePane never requests location.href=about:blank.
"Calling of ClearMessagePane" is needed?

Comment 138

[WADA:World Anti-bad-Duping Agency]

Attachment: button script(v3) to waste time in ClearMessagePane and never request location.href=about:blank (by parameter, same behavior as v2 is supported)

1. Install Custom Buttons addon, add button, paste script.
2. Restart Thunderbird 45, open Error Console.
3. Open new messenger window #X.
   At messenger window #X, click button
   -> modified modules are stored in window.xxx, and eventListener is added.
   Because eventListener is added, "click button" should be executed only once.
4. Do folder switch, message display etc., and clear Error Console,
   and rename imap folder where message in it is shown at message pane.

Comment 139

[WADA:World Anti-bad-Duping Agency]

Short summary of problem.

1. summarizeFolder and his family invokes following just after 1 msec from AnnouncerGoingAway.
   (a) someone requests load of about:blank (current documentURI=imap message URI)
   (b) 1st call of ClearMessagePane
2. If ClearMessagePane accesses contentWindow.location.href, browder.documentURI etc.,
   which is relevant to "unload of old-URI and load of new-URI requested by (a)", 
   during loadContext switching is in progress by request of (a),
   before beforeunload/unload event for request of (a) is invoked,
   exception occurs, and the exception interferes loadContext switching at browser(id=messenger).
3. Once exception and "interfere of loadContext switching at browser(id=messenger)" occurs
   before "beforeunload/unload event for request of (a)" is invoked,
   loadContext/associatedWindow is not recovered until is loadContext/associatedWindow is accessed.
4. If ClearMessagePane wastes time by accessing all properties of big object
   before returning control to summarizeFolder,
   and "beforeunload/unload event for request of (a)" is invoked before end of ClearMessagePane,
   no problem occurs, even if ClearMessagePane won't request location.href=about:blank.
5. If exception doesn't occur before "beforeunload/unload event for request of (a)" is invoked,
   there is no need to access loadContext/associatedWindow for recovery.
   So, "wasting time by accessing many properties of browser object only" is sufficient.
6. If "beforeunload/unload event for request of (a)" is invoked normally,
   there is no need to request location.href=about:blank by ClearMessagePane.

summarizeFolder and his family already utilizes DOMContentLoaded event and CallBack style for "waiting for load completion".
However, summarizeFolder calls old-style blind location.href=about:blank just after 1 msec from AnnouncerGoingAway, despite that his family already requested "load of about:blank".
I think this mismatch is main cause of "interfere of context switch in browser(id=messagepane) during unload+load is in progress.

Comment 140

[Jorg K (CEST = GMT+2)]

I spotted this bug in the "Tracking TB 52" list. A little hard for me to start at comment #140. Anyway, the STR seem to be:

Rename an IMAP folder while having one of its messages selected in the thread pane and viewing it in the message (preview) pane. The preview pane is now broken.

I can easily reproduced this. If you do the same with a local folder, there is no problem.

Comment 141

[Wayne Mery (:wsmwk)]

(In reply to Jorg K (GMT+1) from comment #140)
> I spotted this bug in the "Tracking TB 52" list. A little hard for me to
> start at comment #140. Anyway, the STR seem to be:
> 
> Rename an IMAP folder while having one of its messages selected in the
> thread pane and viewing it in the message (preview) pane. The preview pane
> is now broken.
> 
> I can easily reproduced this. If you do the same with a local folder, there
> is no problem.

correct. Variations of which are stated in bugs which have been marked duplicate

Comment 142

[WADA:World Anti-bad-Duping Agency]

Attachment: button script(v4) to waste time, force delay in loadContext switch, by code in ClearMessagePane, and never request location.href=about:blank

1. Install Custom Buttons addon, add button, paste script.
2. Restart Thunderbird 45, open Error Console.
3. Open new messenger window #X.
   At messenger window #X, click button
   -> modified modules are stored in window.xxx, and eventListener is added.
   Because eventListener is added, "click button" should be executed only once.
4. Do folder switch, message display etc., and clear Error Console,
   and rename imap folder where message in it is shown at message pane.

Even if ClearMessagePane never issues location.href=about:blank,
If ClearMessagePane wasts time by accessing all properties of browser, loadContext, associatedWindow,
beforeunload event and unload event is invoked at old loadContext while ClearMessagePane is wasting time.
The beforeunload/unload is generated by "load of about:blank" which was requested by summarizeFolder or his family just before calling ClearMessagePane after rename imap folder.
If this event occurs at oldContext before end of 1st ClearMessagePane execution after rename imap folder, summarizeFolder works as expected, even if ClearMessagePane never requests location.href=about:blank.
 .

Comment 143

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K (GMT+1) from comment #140)
> A little hard for me to start at comment #140.

Almost all comments can be collapsed by "tag obsolete".

Following are sufficient.
- STR = rename imap folder where message in it is shown in messagepane.
- problem is bypassed by:
  - ClearMessagePane never requests location.href=about:blank
  - ClearMessagePane wastes time by accessing all properties of loadContext and associatedWindow.
    (in default of test setting, all properties of browser element(id=messagepane) is also accessed)

If accessing properties is for window(messenger) only or browser(id=messagepane) only, even if it takes long, beforeunload/unload event is not invoked at old context.
This is perhaps because beforeunload/unload event was cleared by context switch and DOMcontentLoaded/load event was somehow lost.]
I think "accessing loadContext/associatedWindow" forces delay in context switch by "load about:blank request by summarizeFolder family".
So problem can not be bypassed well merely by "wasting time in ClearMessagePanw".
In this case, summarizeFolder never updates messagepane, because;
- summarizeFolder and his family couldn't obtain beforeunload/unload event nor DOMcontentLoaded event at new-url context(about:blank).
- ClearMessagePane never requests location.href=about:blank.
.

Comment 144

[WADA:World Anti-bad-Duping Agency]

My conclusion 2016.

Problem is:
(1) summarizeFolder and his family corrupts loadContext/associatedWindow
    just after rename imap folder(AnnouncerGoingAway).
    "load new-uri(probably about:blank)" is perhaps requested by them just after AnnouncerGoingAway.
(2) summarizeFolder and his family does do nothing,
    if they couldn't obtain beforeunload/unload event at old-url context(imap message)
    nor DOMcontentLoaded event at new-url context(about:blank).
(3) When (2) happens, if location.href != about:blank,
    summarizeFolder and his family does do nothing,
(4) Setting location.href=about:blank is currently job of ClearMessagePane.
(5) If someone including ClearMessagePane accesses location.href, exception occurs, because of (1),
    so no one can set location,href=about:blank as far as state of (1) exists.
    If any of following is called, exception occurs due to (1).
       browser.loadURI(...), browser.docShell.reload(), browser.docShell.loadURI(...),
       xxx=documentURI, xxx=currentURI etc.
    In this case, (2) && (3) occurs in summarizeFolder and his family, so they do nothing.
(6) A known way to bypass problem of (1) && (5) is :
    "access all properties of loadContext and assciatedWindow".
(7) As far as problem of (1) produced by summarizeFolder and his family exists,
    ClearMessagePane need to do bypass of (6).
(7-1) Do bypass of (6) => beforeunload and unload is invoked at old context => (2) doesn't occur.
      However, DOMcontentLoaded/load event at new-url is not invoked even after the bypass.
      In this case, there is no need to refer/touch location.href by ClearMessagePane.
(7-2) Do bypass of (6) => location.href can be accessed/altered after bypass
      => any one including ClearMessagePane can change location.href=about:blank after bypass.
      => if ClearMessagePane does location.href=about:blank, problem of (3) is resolved .

Comment 145

[Jorg K (CEST = GMT+2)]

Quick intermediate analysis result:

In ClearMessagePane() any access to 'messagePane.location' generates an error after renaming (or moving?) an IMAP folder. 'messagePane' appears to be a (semi-healty) object whose keys can be enumerated, however, accessing the value of certain keys, amongst them 'location', fails.

The failure is:
[5792] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file c:/mozilla-source/comm-central/mailnews/base/util/nsMsgMailNewsUrl.cpp, line 524
[5792] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file c:/mozilla-source/comm-central/mailnews/imap/src/nsImapUrl.cpp, line 1179
[5792] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80070057: file c:/mozilla-source/comm-central/mozilla/dom/base/Location.cpp, line 222

So it appears that the IMAP operation didn't do "the right thing"(TM) and clear out the URL from the message pane.

Maybe this information is already known, but it would have taken me longer to read 140+ comments than to diagnose it myself.

As the comment in the code 
  "This can fail because cloning imap URI's can fail ..."
suggests, nsMsgMailNewsUrl.cpp, line 524 is in nsMsgMailNewsUrl::CloneInternal().

So driving the C++ debugger at this will give more clarity. Later, the problem will be to find the spot in the messy IMAP code to "do the right thing".

Comment 146

[Jorg K (CEST = GMT+2)]

The problem is as I said:
nsMsgMailNewsUrl::CloneInternal() calls 
ioService->NewURI(urlSpec, ...
where the urlSpec is something like
  imap://[e-mail]:143/fetch%3EUID%3E.INBOX.HUHUx%3E3"
but that folder doesn't exist any more, since I renamed HUHUx to HUHU.
ioService->NewURI() via a few hoops gets to
nsImapService::NewURI() and that calls
FindOnlineSubFolder() with INBOX.HUHUx" which fails since the folder has been renamed.

In summary: The IMAP folder operation fails to clear out or update the URL displayed in the message pane. The message pane holds on to the old and now invalid URL and nothing works any more. The URL can't be queried and it can't be set either.

So we will need to find the spot where the IMAP folder operation should update the message pane's URL. Or maybe just not complain of the folder isn't found during clone, since the mailbox case doesn't do any such checking, see below.

Comparing this to the mailbox case. Here ioService->NewURI(urlSpec, ...) is also called with the old invalid URL. Here we get to nsMailboxService::NewURI() but that doesn't check any folders, copies the URL spec into the object and returns happily.

Comment 147

[Jorg K (CEST = GMT+2)]

Attachment: 1083994-imap-move.patch (v1)

I think the patch is self-explanatory.

It is just a really bad idea to overload a low-level service with intelligent processing. If you ask for "helllow Doly" to be copied, you want a copy and not the advice that is has two spelling mistakes and can't be copied. This is what happened here.

I'm a little sad that we are at comment #147 for such a trivial fix that I found after a few hours of analysis.

Frankly, I didn't read any of the comments in the bug after working out what the STR are.

I appreciate bug triaging, but keep in mind that TB is a mix of JS and C++, so if you don't do C++ debugging, you're missing a very important part of it.

One word about the regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-01-13+03%3A00&enddate=2014-01-14+05%3A00

I don't have time to analyse this. Most likely there is a subtle change somewhere in the code that clones URIs. Most likely it was changed to pay more attention to errors returned from underlying functions. The FindOnlineSubFolder() has been in nsImapService::NewURI() for a long time.

Kent, all you need to know are the STR:
View a message in an IMAP folder in the message/preview pane.
At the same time, rename the folder.
Try the same with a local folder (which always worked).

Comment 148

[:aceman]

Comment on attachment 8822858 [details] [diff] [review]
1083994-imap-move.patch (v1)

Review of attachment 8822858 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for looking at this!

::: mailnews/imap/src/nsImapService.cpp
@@ +2605,5 @@
>      }
> +    else
> +    {
> +      // If we can't find the folder, we can still create the URI
> +      // in this low-level service. Cloning URIs where is folder

The 'is' seems to be out of place here.

Comment 149

[Jorg K (CEST = GMT+2)]

Attachment: 1083994-imap-move.patch (v1b).

Fixed comment.

Comment 150

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K (GMT+1) from comment #145)
> Maybe this information is already known, but it would have taken me longer
> to read 140+ comments than to diagnose it myself.

No, nothing is known yet. Already known thing what is relevant to IMAP is following only.
- STR = rename IMAP folder when imap message is shown in messagepane, which was repeatedly stated.
  (even when IMAP folder rename, if no mail is shown in messagepane, exception problem doesn't occur)
- "IMAP only problem" what I wrote.
  (no exception problem is observed when rename of local mail folder)

After reading your analysis, I guess that phenomenon is :
"content of browser element(id=messagepane) generated by global/content/bindings/browser.xml"(browser.loadURI, browser.reload etc.) was broken,
due to access/interfere by CPP code(imap code) just when "unload peocess + context switch" started for loading of NewURI=abount:blank.
Phenomenon seems following.
(In ClearMessagePane, does bypass code and accesses all properties of loadContext/associatedWindow),
(but does do nothing on URI, forexampl,e location.href=xxx, browser.loadURI(xxx) etc.)

AnnouncerGoingAway
-> summarizeFolder and his family requests NewURI=about:blank, and waits for DOMContentLoaded event utilizing CallBack
-> by IMAP C++ code, "unload + context switch + load of NewURI=abount:blank" at browser element is interfered
-> beforeunload and unload event is queued,
   context switch is inteferred before context switch completion,
   DOMContentLoaded and load event doesn't occur yet
-> by accessing all properties of loadContext and associatedWindow,
   queued event of beforeunload and unload is scheduled at old-context,
   so exception occurs when browser.currentURI, browser.documentURI etc. is accessed by event listener
-> DOMContentLoaded event for about:blank is not invoked,
   so summarizeFolder and his family does do nothing

Comment 151

[Jorg K (CEST = GMT+2)]

Wada, sadly I don't understand any of what you say. The problem is simply this:

The low-level function that creates an nsIURI object checks whether the IMAP folder addressed by this URI exists. That's simply wrong, you should be able to create/copy/clone a reference, even if the referenced object has gone away. The equivalent mailbox function doesn't check folder existence and it all works.

If have proposed a patch which is awaiting review, so I guess no further work or analysis is required here for now.

Comment 152

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K (GMT+1) from comment #151)
> Wada, sadly I don't understand any of what you say. The problem is simply this:
> The low-level function that creates an nsIURI object checks whether the IMAP
> folder addressed by this URI exists. That's simply wrong, you should be able
> to create/copy/clone a reference, even if the referenced object has gone
> away. The equivalent mailbox function doesn't check folder existence and it
> all works.

Problem is not "URL is not correct" like one.
Problem is :
  browser element(id=messagepane) of XUL, which is implemented by global/content/bindings/browser.xml, was broken,
  and relevant JavaScript object such as loadConterxt, associatedWindow, were also broken,
  after loadContext is exposed by a mozilla-centrl change which was landed between regression window.
Currently known recovery procedure from broken JavaScript object = access all properties of loadContext and accociatedWindow.
After the recovery procedure, about:blank is always set in browser.documentURI, browser.currentURI etc. in this bug's case.

Even if "broken browser XUL element and broken associated JavaScript object in this bug's case" was bypassed by your change,
as far as "interfere of XUL browser element and exposed loadContext" can occur by inappropriate C++ code,
it should be corrected.

Please note following.
  When all properties of loadContext/associatedWindow was accessed to bypass exception problem of this bug,
  exception always occurred only on following 3 properties
  by for(let prop in Obj){ try{let xxx=Obj[prop];}catch(e){save prop name;} } where Obj=loadContext and accociatedWindow.
     layoutHistoryState, canGoBack, canGoForward 
canGoBack and canGoForward is seen in definition of bindings/browser.xml.

Comment 153

[WADA:World Anti-bad-Duping Agency]

Attachment: button script(v5) to bypass exception problem of this bug, merely by accessing properties of loadContext/associatedWindow on Tb 45 without change in IMAP C++ code, with expecting change by bug 916095

FYI.

Even if IMAP C++ code corrupts browser element(id=messagepane), exception of this bug can be bypassed merely by accessing all properties of loadContext/assciatedWindow.

And, after the bypass of exception, thread pane is recovered by merely accessing Folder Properties"(no need to do something at Folder Properties. open Folder Properties, Cancel, is sufficient).
This is manual operation version of patch by bug 916095.

In this trial of workaround of this bug without modification/correction of IMAP C++ code, following is done:
  In ClearMessagePAne called by summarizeFolder,
  nothing is done on URI of browser element(id=messagepane),
  and browser.loadURI(about:about,null,null) like one is requested after 1 sec
  using setTimeout(xxx,1000,...),
  and only when gDBView.numSelected=0,
  browser.loadURI(about:about or about:config,null,null)
  is issued,requested.
By this, "setting about:blank by summarizeFolder with utilizing DOMContentLoaded event and Callback" works as expected, and "setting about:xxx when gDBView.numSelected=0" is also done to bypass problem in current summarizeFolder and loadStartPage".

Outstanding issue in this workaround of "accessing properties of loadContext/associatedWindow + patch by bug 916095" is:
- If "other folder is clicked, then the renamed IMAP folder is clicked",
  last selected message is recovered and the last selected message is shown.
- If "the renamed IMAP folder is forced re-open",
  last selected message is not recovered(lost when thread pane was cleared),
  so message click at thrrad pane is needed to show message in messagepane.

i.e.
Even if your patch is not landed, exception problem of this bug can be worked around.
Your patch is never mandatory change, and is not only one solution, although your patch is correct solution of exception problem of this bug.

Frankly, I'm very appreciated your comments, if your comment was posted in 2014, or was posted when STR(imap is needed, etc.) was stated in this bug and duped bugs, or was posted when regression window was reported in other bug, or was posted before phenomenon/symptom of "broken loadContext" was found in this bug, or was posted before "loadContext was exposed during found regression window" was found in this bug.

Comment 154

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is bug 1062408 comment #9 by aceman on 2014-09-04.
> I can confirm I have seen the bug in operation via Team Viewer. It does happen but it is an IMAP account.
> I am not sure what would chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane fail
> as it seems it expects problems on IMAP and catches them:
> (Comment in ClearMessagePane is referred)
> 1097   try {
> 1098     // This can fail because cloning imap URI's can fail if the username
> 1099     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> 1100     let messagePane = GetMessagePaneFrame();
> 1101     // If we don't do this check, no one else does and we do a non-trivial
> 1102     // amount of work.  So do the check.
> 1103     if (messagePane.location.href != "about:blank")
> 1104       messagePane.location.href = "about:blank";
> 1105   } catch(ex) {
> 1106       logException(ex, false, "error clearing message pane");
> 1107   }

When regression window was reported to bug 1120361 comment #13 : 2016-10-06.

When following bug 1062408 comment #c23 was posted : 2016-11-05.
> I can reproduce the error message after renaming a folder.
When I could observe exception of this bug in my environment : 2016/12. 

(In reply to Jorg K (GMT+1) from comment #147)
> I'm a little sad that we are at comment #147 for such a trivial fix that I found after a few hours of analysis.
> Frankly, I didn't read any of the comments in the bug after working out what the STR are.
> I appreciate bug triaging, but keep in mind that TB is a mix of JS and C++, 
> so if you don't do C++ debugging, you're missing a very important part of it.

Let me know about which comment in which bug(this bug or duped bugs) was first "sufficient/reliable Steps To Reproduce problem".
Please post such comment during 2014.

> One word about the regression range:
> https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2014-01-
> 13+03%3A00&enddate=2014-01-14+05%3A00

It sounds that you could find one relevant bug at a glance from the long list of changes in mozilla-central.
Please post such comment in 2016-10 just after regression window was reported on 2016-10-06.

My pointing is:
(1) XUL browser element was implemented by global/content/bindings/browser.xml.
(2) loadContext was exposed by a change in mozilla-central during the regression window.
(3) After it, even when exception of this bug doesn't happen during ordinal process,
exception always occurs on 3 properties by try{let xxx=Obj[prop];}catch(e){ PropArray[PropArray.length]=prop;}
where Obj=browser(id=messagepane).loadContext and browser(id=messagepane).loadContext.associatedWindow.
(4) It looks that exception of this bug was produced by "C++ code puts wrong nsURI object to XPCOM object which XUL browser uses".
(I suspecteded imap code, but I thought URI change was made via. standatd interface of XUL element named browser which is XPCOM object.)
(5) If action by C++ code is correct, "loadContext and relevant context switch" should be removed from Thunderbird.
(6) If "loadContext and relevant context switch" is accepted by Thunderbird, behavior of C++ code should be corrected.
(7) Even if "exception of this bug upon imap folder rename" is bypassed by "setting correct URI object" or "don't replace URI object when folder is lost", problem of above (3) still remains.
It indicates something is wrong in processing of XUL element named browser(id=messagepane) which is XPCOM object.
If "loadContext and relevant context switch" is accepted by Thunderbird, C++ code is better to change "URI in XUL browser element(id=messagepane)" via. standard interface of XUL browser element, for example, browser.setTimeout("this.loadURI(about:xxx,null,null);",1).

(8) If CleareMessagePane is changed to as follows, mystery of comment in ClearMessagePane disappears.
  ClearMessagePane
   document.getElementById("messagepane").setTimeout(StartPageLoader,1000);
   return; // -> caller of ClearMessagePane==summarizeFolder and his family continues his job
   // "DOMContentLoaded event and load event for newURI = about:blank" is invoked, so summarizeFolder works as expected.
   // it looks 200-300msec is needed to wait for clearTimeout completion in summarizeFolder and his family.
  StartPageLoader()
   let RequiredURI = startup page if prefs requests startup page,
       or about:xxx (any of about:blank, about:about, about:config, ...), or "http://www.google.com" etc.
   if(gDBView && !(0<gDBView.numSelected) && this.contentWindow.location.href != RequiredURI ) 
      this.loadURI(RequiredURI,null,null) ;
   // What was needed by ClearMessagePane was never "setting location.href=about:blank".
   // What was needed was "DOMContentLoaded event for summarizeFolder" when nothing is selected at thrreadPane.
   // By this change from current loadStartPage,
   // startpage or about:xxx is shown as expected when no message is selected at threadPane.

Comment 155

[Jorg K (CEST = GMT+2)]

(In reply to WADA:World Anti-bad-Duping Agency from comment #154)
> Please post such comment during 2014.
I first saw this bug on 2016-12-30 at 15:17:41 my time.
It is impossible to post comments retrospectively in 2014.

> Please post such comment in 2016-10 just after regression window was
> reported on 2016-10-06.
Again, impossible, as I first saw this bug at the end of Dec. 2016.

Can we PLEASE close the discussion now and wait for the review. Personally, I'm not interested in loadContext or summarizeFolder or anything else.

The sad fact is that with the message pane having a location that is an IMAP URI pointing to a non-existent folder, absolutely NOTHING will work, since the location cannot be read (messagePane.location.href != "about:blank" just fails, in fact, accessing messagePane.location already fails) and it cannot be set either. I also do not care how this regressed, since the code in nsImapService::NewURI() is wrong and was always wrong (only that apparently no one noticed).

This case is really CLOSED unless Kent doesn't agree with the fix. I will also ignore any further comments what are not related to the patch.

Comment 156

[WADA:World Anti-bad-Duping Agency]

(In reply to Jorg K (GMT+1) from comment #155)

Personally, I'm not interested in who/how puts wrong URI(points non-existent folder) in XUL browser element, because exception of this bug is pretty easily bypassed and disappears merely by "accessing all properties of loadContext/associatedWindow" which takes merely a few milliseconds. Because exception of this bug is imap only problem(someone and I wrote so), developers will check imap code sooner or later.

I'm interested in follwing comment in ClearMessagePane, because this bug is relevant to ClearMessagePane function.
> 1098     // This can fail because cloning imap URI's can fail if the username
> 1099     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> 1100     let messagePane = GetMessagePaneFrame();
> 1101     // If we don't do this check, no one else does and we do a non-trivial
> 1102     // amount of work.  So do the check.
You are perhaps interested in "cloning imap URI's" part. (I was aware of it after I read your comment on imap code in this bug...)
I'm intersted in "If we don't do this check, no one else does ..." part.

I'm interested in why XUL browser element, loadContext, context switch at browser element, was broken merely by an URI object which was put by imap C++ code?
"Exception in this bug(ILLEGAL VALUE)" occurs in "unload process invoked by load of newURL=about:blank", because URL object in browser element stored by IMAP C++ code(which should be unloaded) points non-existent folder URL?

I'm interested in why property of XUL browser element, property of loadContext/associatedWindow, is always partially broken, even when "unload/load of URL in XUL browser element" is executed without exception. Following is bad?
 Replacing "URI object which is used by XUL browser element" by C++ code while XUL browser code is doing something on URL.

Comment 157

[WADA:World Anti-bad-Duping Agency]

> If have proposed a patch which is awaiting review, so I guess no further work or analysis is required here for now.

To Jorg K.
Yes of course, there is no need of your further work in this bug.
As I already wrote, this bug is kept open to analyze outstanding/still-unclear issues before opening new bug for fix creation.
Please open new/crisp bug for your patch creation without posting useless comments in this bug any more.

Comment 158

[WADA:World Anti-bad-Duping Agency]

FYI.

Following is log by eventListner for unload event and DOMContentLoaded event when displayed message was changed from UID=3 to UID=7
3 kinds of URI in browser element are obtained by next code.
  let documentURI = this.documentURI.spec ;
  let  currentURI =  this.currentURI.spec ;
  let pendingOrLoadedUrl = this.docShell
      ? this.contentDocument.location.href
      : "about:blank";
"this" in context of the eventListener is browser element(id=messagepane).

status = event=unload (unload of UID=3)
currentURI=documentURI=imap://[e-mail]:993/fetch%3EUID%3E/FolderX%3E3,
pendingOrLoadedUrl=imap://imap.gmail.com:993/fetch%3EUID%3E/FolderX%3E3,

status = event=DOMContentLoaded (load of UID=7)
currentURI=documentURI=imap://[e-mail]:993/fetch%3EUID%3E/FolderX%3E7,
pendingOrLoadedUrl=imap://imap.gmail.com:993/fetch%3EUID%3E/FolderX%3E7,

summarizeFolder and CallBack for load check is done by using DOMContentLoaded event and they seems to look pendingOrLoadedUrl.
I don't know about that imap C++ code replaces which kind of URI in which property of browser element.
But if browser.contentDocument.location.href is touched, different phenomenon may occur from replacing documentURI/currentURI etc.

Comment 159

[WADA:World Anti-bad-Duping Agency]

Because bug 1062408, which is first/oldest bug report about exception in imap folder rename, was closed as dup of this bug, I started to do problem analysis work from 2016/12/21 when I could reproduce exception of this bug on 2016/12/21 at last(comment #65).
If patch is proposed, I think it should be proposed in one of bug 1062408(first report) or new crisp bug for patch creation, with summarizing important information such as clear/fully-stated Steps To Reproduce, detail of phenomenon/problem, regression window, and so on. 
Please stop behavior like next.
  because a developer was interested in a bug report, a patch was proposed to the bug,
  then all activities were consolidated to the already long bug report,
  and other bugs for same problem were closed as dup of the long bug,
  merely because that a first patch proposal was attached to the long bug.

Comment 160

[Wayne Mery (:wsmwk)]

Thanks for all the great progress.  I think it makes great sense to cover the imap issue in a new bug, so I have taken the liberty of creating Bug 1328814.  And this bug can continue to cover the non-imap issues.

Comment 161

[Wayne Mery (:wsmwk)]

And I look forward to my annual/biannual great email cleanup facilitated by a fix :)

Comment 162

[Jorg K (CEST = GMT+2)]

I have un-CC'ed myself from this bug since it is simply a non-issue once bug 1328814 has landed.

(In reply to WADA:World Anti-bad-Duping Agency from comment #156)
> I'm interested in why XUL browser element, loadContext, context switch at
> browser element, was broken merely by an URI object which was put by imap
> C++ code?
Yes.

> "Exception in this bug(ILLEGAL VALUE)" occurs in "unload process invoked by
> load of newURL=about:blank", because URL object in browser element stored by
> IMAP C++ code(which should be unloaded) points non-existent folder URL?
Yes.

Look at the obsolete patch to see where the error was raised in the low-level function. Please read comment #155:

===
The sad fact is that with the message pane having a location that is an IMAP URI pointing to a non-existent folder, absolutely NOTHING will work, since the location cannot be read (messagePane.location.href != "about:blank" just fails, in fact, accessing messagePane.location already fails) and it cannot be set either.
===

You understand "NOTHING will work"? Thunderbird accesses everything (messages, attachments, addresses, etc.) using specialised mailbox, IMAP (or other types of) URIs. That's how it interfaces with the Gecko rendering engine. If access to those URIs doesn't work due to an error in a low-level function, nothing works.

Is that so hard to understand? If after bug 1328814 has landed you can still find a problem, let me know.

Comment 163

[WADA:World Anti-bad-Duping Agency]

Another questions.
(1) Why no error in 2014-01-13 build(just before loadContext is exposed), even though Thunderbird code, imap code is not so largely changed between 2014-01-13 and 2014-01-14?
(2) Why exception problem disappears merely by accessing all properties of loadContext and associatedWindow?
By accessing other properties, getter etc. is properly set up, then null or undefined is returned for wrong URI object replaced by imap C++ code?
(3) No problem in "exception on 3 properties of loadContext/associatedWindow always"?
I think this is an indicator of "bad accessing to XUL browser element/its property from Tb's C++ code".

Thanks for splitting to new bug.
By your analysis, last mystery in this bug of "who/when/how broke browser element" disappeared.

Outstanding issues in this bug:
Mysteries which was found in this bug while analyzing/testing ClearMessagePane and other modules.

(A) Biggest mystery is following comment.
> 1098     // This can fail because cloning imap URI's can fail if the username
> 1099     // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> 1100     let messagePane = GetMessagePaneFrame();
> 1101     // If we don't do this check, no one else does and we do a non-trivial
> 1102     // amount of work.  So do the check.

I think "cloning imap URI's can fail" part is probably covered by your patch.
However, "If we don't do this check, no one else does" part requires some improvements in summarizeFolder, ClearMessagePane, loadStartPage etc.
- IIRC, startup page was always shown when no message is selected at threadPane.
  However, in Tb 45, startup page was shown from restart of Tb till "first message display at messagepane" only. 
  This is due to code of loadStartPage. loadStartPage is coded, so, startup page is shown so.
- "Request of load about:xxx by ClearMessagePane" was needed on ly when gDBView.numSelected=0
  (no message is selected at threadPane, because nothing is shown at threadPane, or nothing is selected yet at threadPane)
  In all other cases, summarizeFolder and relevant code processes every thing well,
   so, there is no need to request load of about:blank by ClearMessagePane, except when gDBView.numSelected=0.

Some other small issues in showing message/startpage/about:blank etc. in XUL browser element(id=messagepane).
Even though it's XUL *browser* element, it's treated as-if merely an XUL box element like message header box, attachment box, at some places. Because it's browser element, setTimeout etc. is better requested to browser.contentWindow in some cases, and it's better requested to browser(id=messagepane) in some cases, but it's better requested to window(DOM window of messenger) in some cases because this is chrome code.

Comment 164

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #160)
> so I have taken the liberty of creating Bug 1328814. And this bug can continue to cover the non-imap issues.

Wayne, thanks for opening new bug. I believe you read and understood comment #123 :-)

Missing ring of "who/when/how broke browser element" was discovered by Jorg K at last.

(Off-Topic)
When regression window was discovered=2016/10, when aceman could observe exception=2016/11, when I could reproduce exception = 2016/12/21.
I couldn't be aware of "regression window" until I read response of comment #71 from aceman after I could reproduce exception of this bug on 2016/12/21.
Why many peoples failed to reproduce problem of this bug, even though bugs for exception problem were opened in 2014, even though this bug is 100% reprodicible once "fully-described STR" was stated at some where? Jorg K joined to this bug's problem on 2016/12/30 as known by his comment #155, and he could reproduce problem pretty easily.

I believe something should be improved in B.M.O.

Comment 165

[capndave]

Original reporter here.

Here is a fresh error log from Thunderbird 45.6.0.

Hit while doing basic operations on imap folders.
As a reminder, once the problem starts only an app restart will remedy it.
If I clear the error log and then click on any folder here is the isolated set of errors messages.

Timestamp: 1/5/17, 11:55:57 AM
Error: error clearing message pane
Source File: resource:///modules/errUtils.js
Line: 34

Timestamp: 1/5/17, 11:55:57 AM
Error: [Exception... "Illegal value"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: chrome://messenger/content/msgMail3PaneWindow.js :: ClearMessagePane :: line 1069"  data: no]
Source File: resource:///modules/errUtils.js
Line: 35

Comment 166

[Wayne Mery (:wsmwk)]

IF anything is done here, I want to be sure we don't forget about bug 545933

Comment 167

[WADA:World Anti-bad-Duping Agency]

(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #166)
> IF anything is done here, I want to be sure we don't forget about bug 545933

Quick history of ClearMessagePane is as follows.
If "delete message case in bug 545933" is simple "Non OK return code from imap C++ code when URL object is accessed via such as browser.currentURL upon trying to load NewURL such as about:blank" case, I think exception didn't occur upon "location.href=about:blank by ClearMessagePane" as no error occurred in "imap folder rename" case before "expose of loadContext".
It may be exception in imap code when special condition occurs on msgDBHdr and UID of deleted mail(\Deleted is stored). If "Remove immediately", msgDBHder is removed just after "store +Flags(\Deleted)", and "UID of deleted mail" can be expunged immediately just after "store +Flags(\Deleted").

> ----------------------------------------------------------------------------------------------------------------
> |                                  | (Case-A) imap folder rename | (Case-B) imap message delete                |
> |                           Cases  |   currentURI=FolderX,UID=ZZ |   currentURI=FolderX,UID=ZZ                 |
> |                                  |---------------------------------------------------------------------------|
> |                                  | rename to FolderY           | delete message of UID=ZZ                    |
> |                                  | => FolderX desn't exist     | => FolderX still exists                     |
> |                                  |                             |---------------------------------------------|
> |                                  |                             | "msgDBHdr remains or not after delete"      |
> |                                  |                             |     depends on imap delete model            |
> |                                  |                             | "UID=ZZ exists or not after store \Deleted" |
> |                                  |                             |     depends on Expunged state at server"    |
> |                                  |                             |---------------------------------------------|
> |                                  |                             | msgDBHdr for UID=ZZ | O | O | X | X |       |
> |                                  |                             |---------------------------------------------|
> |                                  |                             | UID=ZZ at server    | O | X | O | X |       |
> ----------------------------------------------------------------------------------------------------------------
> |2010-02 :                         | Exception never occurred    | Exception might have happened               |
> | Bug 545933 was opened,           |   because no referring      |   some times in some cases,                 |
> | loaction.href=about:blank        |   to imap folder rename     |   so, location.href=about:blank             |
> | was moved in to try block,       |                             |   was moved to try.catch block              |
> | with folowing comment            |                             |                                             |
> | // This can fail because cloning |                             |                                             |
> |    imap URI's can fail           |                             |                                             |
> |    if the username               |                             |                                             |
> | // has been cleared by           |                             |                                             |
> |    nsDefaultURIFixup.cpp.        |                             |                                             |
> ----------------------------------------------------------------------------------------------------------------
> |2010-04-22 :                      | Exception perhaps never     |                                             |
>   Bug 545955 was fixed.            |   occurs, because no report | ?????                                            |
> | loaction.href=about:blank        |   on exception              |                                             |
> | was moved into                   |                             |                                             |
> | if(location.href!=about:blank)   |                             |                                             |
> - block, with following comment    |----------------------------------------------------------------------------
> | // If we don't do this check,4   | I think comment means :                                                   |
> |    no one else does              |   If location/href=about:blank is not done here,                          |
> |    and we do a non-trivial       |   no one changes url of browser(id=messagepane)                           |
> | // amount of work.               |   when no mail is selected at threadPane(gDBView.numSelected=0).          |
> |    So do the check.              |   (no message in folder, no message is selected after restart/rename)     |
> ----------------------------------------------------------------------------------------------------------------
> |                                  | Exception perhaps never     |                                             |
> |2011 to 2013 :                    |   occurs, because no report | ?????                                       |
> |                                  |   on exception              |                                             |
> ----------------------------------------------------------------------------------------------------------------
> |                                  | Exception surely never      |                                             |
> |2014-01-13 :                      |   occurs, as known by       | ?????                                       |
> |                                  |   regression window         |                                             |
> ----------------------------------------------------------------------------------------------------------------
> ---- (loadContext was exposed) ---------------------------------------------------------------------------------
> ----------------------------------------------------------------------------------------------------------------
> |                                  | Exception started to occur. | Similar to "imap folder rename" case,       |
> |2010-01-14                        | Exception surely occurs     | because currentURl may not be valid         |
> |   and after :                    |   as known by               | after delete of imap message.               |
> |                                  |   regression window.        | However, same as "imap folder rename" case? |
> ----------------------------------------------------------------------------------------------------------------

Comment 168

[WADA:World Anti-bad-Duping Agency]

Sorry, wrong regression date. Correct regression window is 2014-01-13 and 2014-01-14.
> ----------------------------------------------------------------------------------------------------------------
> ---- (loadContext was exposed) ---------------------------------------------------------------------------------
> ----------------------------------------------------------------------------------------------------------------
> |                                  | Exception started to occur. | Similar to "imap folder rename" case,       |
> |2014-01-14                        | Exception surely occurs     | because currentURl may not be valid         |
> |   and after :                    |   as known by               | after delete of imap message.               |
> |                                  |   regression window.        | However, same as "imap folder rename" case? |
> ----------------------------------------------------------------------------------------------------------------

Comment 169

[WADA:World Anti-bad-Duping Agency]

Attachment: Addon to continue testing relevant issues without waiting for fixing in imap C++ code, without waiting for new Custome Buttons

To continue testing on Tb 52, Tb 53, Button Script was moved to addon for Thunderbird.

Install addon, add button 3 to toolbar via. Customize Toolbar.
Open new messenger window(messenger #x), at ClearMessagepane menu, choose "load about:support/about", or "load about:blank".
To see what is done easily, about:support is shown instead of about:blank by ClearMessagePane if Startup Page is defined by option setting, and about:about is shown instead of about:blank is startup page is not defined by option setting.

This is to know that "about:blank is never mandatory URI" and that "load of something" is to clear garbage of previously shown message at messagepane when folder is switched but no mail is selected at threadPane after the folder switch(no mail in newly selected folder, no last selected message in the folder).

To bypass exception problem due to ILLEGAL VALUE returned by IMAP C++ code, all properties of browser(id=messagepane).loadContext is accessed before accessing currentURI, location etc.
By it, "unload of previous URI regardless of state of currentURI" is forced, and documentURI/currentURI/location etc. ia set to about:blank without load of about:blank URI.

By it, fix verifiction test of bug 916095 was done without intefere by this bug.

Comment 170

[WADA:World Anti-bad-Duping Agency]

I misunderstood about "beforeunload/unload event just after accessing all properties of loadContext" and NewURI of about:blank after it without DOMContentLoaded/load event.
I thought someone alredy requested "load of about:blank", but it was wrong.
It was:
By accessing all properties of loadContext, currentURI(non existent imap folder URI after rename folder in this bug's case) is unloaded regardless of state of currentURI, and URI of about:blank is set without "loading process of about:blank URI".
i.e. "accessing all properties of loadContext" can be currently used as a mothod for "forcing unload of currentURI without loading an URI".
Because "load of about:blank" is not done by "accessing all properties of loadContext", DOMContentLoaded/load event won't be invoked, and content in messagepane(garbage of last shopwn message) is not cleared by it. So, loadURI, location.href etc. is needed to clear garbage of last shown message in messagepane.

Comment 171

[WADA:World Anti-bad-Duping Agency]

Oh, bug 1328814 has been fixed on 1/10. Will be landed on trunk soon.

Comment 172

[WADA:World Anti-bad-Duping Agency]

About Move/Delete message and ClearMessagePane.

From perspective of ClearMessagePane, move/delete message is absolutely irrelevant, because ClearMessagepane is currently never called by move/delete message.
"move/delete of a message" is merely a "switch of selected message at threadPane", and is executed by "load of newly selected message" which will invokes "beforeunload/unload event for URI of previously selected message" and "DOMContentLoaded/load event for URI of newly selected message".

I can't understand reason why following comment #166 was posted in this bug long the way by Wayne Mery.
> IF anything is done here, I want to be sure we don't forget about bug 545933

Following is change by Bug 545933.
> Bug 545933 : deleting messages sometimes throws an uncaught exception in ClearMessagePane
> https://hg.mozilla.org/comm-central/diff/7a592c39b832/mail/base/content/msgMail3PaneWindow.js
> -  GetMessagePaneFrame().location.href = "about:blank";
> +  try {
> +    // This can fail because cloning imap URI's can fail if the username
> +    // has been cleared by docshell/base/nsDefaultURIFixup.cpp.
> +    GetMessagePaneFrame().location.href = "about:blank";
> +  } catch(ex) {
> +      logException(ex, false, "error clearing message pane");
> +  }

In old code, ClearMessagePane might have been called upon message switch too.
However, if cause is IMAP C++ code, it should be requested to bug 1328814 instead of this bug, shouldn't it?

Comment 173

[WADA:World Anti-bad-Duping Agency]

In bug 545933, David says "delete all messages in Junk" and "two imap accounts on same imap server".
"delete all messages in Junk" == "Empty Junk Folder"?
If so, "Empty Junk" is perhaps "Delete Junk folder, then re-create Junk folder", as done by "Empty Trash".
And, when multiple accounts are defined on same imap server, null pointer was returned and exception happened.

If so, original problem is perhaps different from this bug(== bug 1328814).

That bug : due to bug in IMAP code when multiple acounts are defined on same imap server, object relevant to location was broken. 

This bug(== bug 1328814) is perhaps :
Internal spec was changed on Return Value when loadContext was exposed, but IMAP C++ code can not follow the spec change.

1. IMAP C++ code returns Non NS_OK(call NS_ERROR) for long time when previously seletcd folder doesn't exist any more.
2. Before loadContext is exposed, browser.xul/DocShell etc. has two state only : NS_OK, not NS_OK,
   and if not NS_OK, ignore it upon unload of old URI because of "Not NS_OK".
3. After loadContext is exposed, browser.xul/DocShell etc. has multiple states :
   LEGAL values(Ok values, Non-OK values) and Non-LEGAL(ILLEGAl values)
   Fortunately, NS_OK returned by IMAP C++ code == LEGAL value,
   but unfortunately, NS_ERROR returned by IMAP C++ code ==  ILLEGAl values, so exception happened.
4. In bug 1328814, LEGAl NS_OK is returned when previously selected folder doesn't exist any more.

Anyway, although it took 3 years to discover "what happened in this bug, what is problem in this bug", exception is successfully detected and reported by try/catch block introduced in bug 545933 by David :Bienvenu.

Comment 174

[Jorg K (CEST = GMT+2)]

Not tracking this any more since IMHO the main aspect got fixed by bug 1328814. I don't know whether this bug is still relevant, since frankly, I never understood the issue(s). In case it's not relevant any more, please close it.

Comment 175

[capndave]

With all due respect to Jorg K, I see no point in closing this as a duplicate.

> I don't know whether this bug is still relevant
I hit this bug literally dozens of times per day.  There is no workaround - only a restart of Thunderbird.
I cannot migrate to another client, so I continue to deal with it until the bleeping bug is fixed.

> frankly, I never understood the issue(s)
Then why close it as a "duplicate" of another.

> since IMHO the main aspect got fixed by bug 1328814
Bug 1328814 is merely targeted for Thunderbird 53.0.  When the fix for Bug 1328814 is built and verified,
then this bug can be closed.  I await the day that I can verify a prototype of this fix.

> please close it.
I could not disagree more.  This bug has been a showstopper for me for years and is now only getting the
attention it originally deserved when I first reported in back in 2014.

Again, I say these things with all due respect, as you are a respected contributor.

Comment 176

[Wayne Mery (:wsmwk)]

(In reply to capndave from comment #175)
> With all due respect to Jorg K, I see no point in closing this as a
> duplicate.

Let's forget all that for the moment.  dapndave, you can test the patch that was made in bug 1328814 using beta from http://www.mozilla.org/en-US/thunderbird/channel/  It's working for me.


Now, IMO it's premature to be talking about closing/duping/whatever for this bug until all the code wada has mentinoed is correct, regardless of whether bug 1328814 fixes the root cause.  Further, the fix needs a full vetting in an actual release.

Comment 177

[capndave]

Wayne,

I have run the Betas for 5 weeks and did not hit a single issue.

I ran 52.0b2 for 3 weeks with an upgrade install.
I ran 52.0b3 for 2 weeks from a clean os install, tb install, imap pull and complete global indexing.

Usage was heavy and included hundreds of folder renames/creates/moves/deletes.
Message preview pane was always visible, no need to reboot TB, no related messages in error console.

From my point of view, as the original reporter, I consider the issues fixed in the Beta and look
forward to it being taken up into the mainline.

Thanks all for your efforts.  Happy TB user again.

Comment 178

[capndave]

To add. The make up my live email structure used for testing is:
IMAP: Approx 2GB, 25,000 messages, 500 folders, 200 sub, 100 sub-sub.
Local: Approx 24GB, 1M+ messages, 20,000+ folders, 10,000+ sub,  5,000 sub-sub.
95% operations on IMAP.
5% operations on Local.