Open Bug 1083994 Opened 7 years ago Updated 2 years ago

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)

Categories

(Thunderbird :: Message Reader UI, defect)

31 Branch
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: capndave, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [regression:TB29][Exception problem part is fixed by bug 1328814])

User Story

regression window(trunk) reported by bug 1120361 comment #13  :  
   [2014-01-13, 2014-01-14]
 (regression of "messagepane is broken after rename of imap folder, new messenger window open is needed")

recovery procedure from this bug :
  open new messenger window(3pane window), then close old messenger window.

a workaround :
  don't execute rename/move of using/active/selected imap folder.
  when not selected at folder pane, right click(never click), do rename/move folder.

Attachments

(1 file, 8 obsolete files)

274.81 KB, application/x-xpinstall
Details
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.
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.
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/
Flags: needinfo?(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.
Flags: needinfo?(capndave)
see comment 3.  I hesitate to all this a regression just yet.
Flags: needinfo?(acelists)
Anything in Tools->Error console after the body does not display?
Have you tried repairing the folder in rightclick->Properties->Repair?
Flags: needinfo?(acelists)
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

...
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.
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.
Severity: normal → critical
Priority: -- → P2
Keywords: regression
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?
Change platform to All, since this has also now been verified on Linux.
OS: Windows 7 → All
Hardware: x86_64 → All
Assigned to Message Reader UI, given the logs in Comment 6.
Component: Untriaged → Message Reader UI
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.
Still reproducible using the 31.3.0 update.
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.
Severity: critical → blocker
Priority: P2 → P1
(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.
Severity: blocker → major
Flags: needinfo?(capndave)
Priority: P1 → --
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.
Flags: needinfo?(capndave)
(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.
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?
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://first%2Elast%40company%2Ecom@sub.domain.com: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.
> 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
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
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?
Flags: needinfo?(neil)
(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?
Flags: needinfo?(neil)
> 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 neil@parkwaycc.co.uk 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?
Flags: needinfo?(acelists)
(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?
Flags: needinfo?(capndave)
Summary: Regression : v31 : Highly reproducible inability to view the message body in the message pane. → Regression : v31 : view the message body in the message pane fails with "Automatically mark messages as read"
Whiteboard: [regression:TB??]
(In reply to Wayne Mery (:wsmwk) from comment #24)
> (In reply to neil@parkwaycc.co.uk 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.
Flags: needinfo?(acelists)
> 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
Flags: needinfo?(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.
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.
Summary: 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.
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
same symptoms on ubuntu 15.04 thunderbird 38.2.0; workaround is to switch view/layout back/forth
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
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
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");
adding exception data in bug summaary for ease of search.
Summary: Regression : v31 : Inability to view message body in the message pane, requiring reboot of TB. → Regression : v31 : Inability to view message body in the message pane, requiring reboot of TB. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 )
(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.
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");
> }
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)?
(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
(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}
   );
}
(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
(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
"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 }
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 :)
(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?(mkmelin+mozilla)
Flags: needinfo?(m-wada)
(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?(m-wada@usa.com)

Sorry, but I don't know.
Flags: needinfo?(m-wada)
Nothing comes to mind, sorry.
Flags: needinfo?(mkmelin+mozilla)
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
Severity: major → blocker
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.
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
Severity: blocker → major
Status: UNCONFIRMED → NEW
Depends on: 1062408
Ever confirmed: true
Summary: Regression : v31 : Inability to view message body in the message pane, requiring reboot of TB. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 ) → view message body fails in the message pane, requiring restart of TB. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 )
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
(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
Flags: needinfo?(capndave)
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.
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
No longer depends on: 1062408
Flags: needinfo?(capndave) → needinfo?(acelists)
Whiteboard: [regression:TB??] → [regression:TB29]
Duplicate of this bug: 1120361
Duplicate of this bug: 1062408
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?
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)
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?
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.
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.
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.
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   ?       ?             ?       ?             ?                  ?                      ?
aceman, what do you think about problem of this bug and bug 520115?
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
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"?
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?
Flags: needinfo?(acelists) → needinfo?(vseerror)
(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.
Summary: view message body fails in the message pane, requiring restart of TB. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 ) → view message body fails in the message pane, requiring new messenger window open. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 )
Duplicate of this bug: 1292170
Duplicate of this bug: 1248660
User Story: (updated)
capndave@hotmail.com(bug opener), can you check regression window by trunk nightly? (see User Story, please)
(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.
Flags: needinfo?(vseerror)
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)
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.
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.
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.
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).
Summary: view message body fails in the message pane, requiring new messenger window open. ( "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMLocation.href]" at ClearMessagePane :: line 1103 ) → view message body fails in the message pane, requiring new messenger window open. (After rename of imap folder where mail is shown in messagepane, "Component returned failure code: 0x80070057 [nsIDOMLocation.href]" in ClearMessagePane)
Duplicate of this bug: 1193885
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.
See Also: → 916095
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...
Sorry, correction of comment #84: which was closed as dup of a bug,
> +  _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.
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.
Oh, problem of this bug was referred by Bug 916095 comment #14 with pointing bug 1062408 which was closed as dup of a bug...
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.
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" ;
User Story: (updated)
Summary: view message body fails in the message pane, requiring new messenger window open. (After rename of imap folder where mail is shown in messagepane, "Component returned failure code: 0x80070057 [nsIDOMLocation.href]" in ClearMessagePane) → 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)
User Story: (updated)
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?
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.
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://yatter.one%40gmail.com@imap.gmail.com/INBOX/[Inbox99X/[Inbox99]/FolderZ, parentItem.URI=imap://yatter.one%40gmail.com@imap.gmail.com/INBOX/[Inbox99X/[Inbox99]
>  DateTime=2016/12/25 16:45:17.328 GMT, EventType=Folder_ItemAdded, item.URI=imap://yatter.one%40gmail.com@imap.gmail.com/INBOX/[Inbox99X/[Inbox99]/FolderX, parentItem.URI=imap://yatter.one%40gmail.com@imap.gmail.com/INBOX/[Inbox99X/[Inbox99]
>  DateTime=2016/12/25 16:45:17.355 GMT, EventType=RenameCompleted, FolderURI=imap://yatter.one%40gmail.com@imap.gmail.com/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
(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
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?
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.
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?
(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.
(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...
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.)
Attachment #8821839 - Attachment description: Button script to replace window.ClearMessagePane for getting timestamp log of ClearMessagePane and doing bypass of exception → Button script (V1) to replace window.ClearMessagePane for getting timestamp log of ClearMessagePane and doing bypass of exception(bypass is done after exception)
Attachment #8822367 - Attachment description: Event log when imap folder rename, obtained by added code to ClearMessagePane, other eventListerners for folder event and event on messagepane/threadPane → 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)
Attachment #8822579 - Attachment description: button script(v2) to add code for "bypass exception in ClearMessagePane" → button script(v2) to add code for "bypass exception in ClearMessagePane"(bypass is done before location.href access)
FYI.
I've opened bug 1326371 and bug 1326375 for loadStartPage.
See Also: → filterbar, 1326371, 1326375
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.
(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
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".
The problem is as I said:
nsMsgMailNewsUrl::CloneInternal() calls 
ioService->NewURI(urlSpec, ...
where the urlSpec is something like
  imap://jorgk%40jorgk%2Ecom@mail.your-server.de: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.
Attached patch 1083994-imap-move.patch (v1) (obsolete) — Splinter Review
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).
Assignee: nobody → jorgk
Attachment #8822367 - Attachment is obsolete: true
Attachment #8822689 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8822858 - Flags: review?(rkent)
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.
Attached patch 1083994-imap-move.patch (v1b). (obsolete) — Splinter Review
Fixed comment.
Attachment #8822858 - Attachment is obsolete: true
Attachment #8822858 - Flags: review?(rkent)
Attachment #8822875 - Flags: review?(rkent)
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.
(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.
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.
And I look forward to my annual/biannual great email cleanup facilitated by a fix :)
Assignee: jorgk → nobody
Status: ASSIGNED → NEW
See Also: → 1328814
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.
Attachment #8822875 - Attachment is obsolete: true
Attachment #8822875 - Flags: review?(rkent)
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.
Depends on: 1328814
Whiteboard: [regression:TB29] → [regression:TB29][Exception problem part will be fixed by bug 1328814]
(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.
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
IF anything is done here, I want to be sure we don't forget about bug 545933
Blocks: 545933
(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? |
> ----------------------------------------------------------------------------------------------------------------
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? |
> ----------------------------------------------------------------------------------------------------------------
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.
Attachment #8823627 - Attachment is obsolete: true
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.
Oh, bug 1328814 has been fixed on 1/10. Will be landed on trunk soon.
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?
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.
No longer blocks: 545933
See Also: → 545933
No longer blocks: 520115
See Also: → 520115
Whiteboard: [regression:TB29][Exception problem part will be fixed by bug 1328814] → [regression:TB29][Exception problem part is fixed by bug 1328814]
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.
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.
(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.
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.
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.
Severity: major → normal
You need to log in before you can comment on or make changes to this bug.