Fixed.  Turned out this wasn't an issue in 5.1 because another bug was 
preventing any view from being purged from the viewport cache.  In 
other words, it was working in IMP 5.1 by accident.

Changes have been made in Git (develop):

commit 590f727ca0f2793222975d2a8d2c5112c075f830
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Feb 1 13:54:28 2012 -0700

     [mms] Fix reloading the folder list in the dynamic view (Bug #10769).

  imp/docs/CHANGES   |    1 +
  imp/js/viewport.js |    5 +++++
  imp/package.xml    |    2 ++
  3 files changed, 8 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/590f727ca0f2793222975d2a8d2c5112c075f830

Changes have been made in Git (master):

commit 590f727ca0f2793222975d2a8d2c5112c075f830
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Feb 1 13:54:28 2012 -0700

     [mms] Fix reloading the folder list in the dynamic view (Bug #10769).

  imp/docs/CHANGES   |    1 +
  imp/js/viewport.js |    5 +++++
  imp/package.xml    |    2 ++
  3 files changed, 8 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/590f727ca0f2793222975d2a8d2c5112c075f830

Ahhh... this isn't broken in 5.1, only in 5.0.x.  So we need a hotfix 
just for 5.0.x.

1. Go to Inbox
2. Select a message
3. Toggle subscribed/unsubscribed folders (direction doesn't matter) 
=> triggers pasted backtrace
4. Hit reply

Still not reproducing.  I am going to need a step-by-step way of reproducing.

Narrowed it down further: it only happens in INBOX. And the INBOX view 
is explicitly deleted, this is the backtrace (1 or 2 lines off in 
dimpbase.js):

deleteView(view="SU5CT1g")viewport.js (Zeile 354)
deleteFolderElt(fid="fldSU5CT1g", sub=true)dimpbase.js (Zeile 3124)
(?)(elt=li#fldSU5CT1g.folder)dimpbase.js (Zeile 3150)
each(value=li#fldSU5CT1g.folder)prototype.js (Zeile 825)
each(iterator=function(), context=Object { INBOX="SU5CT1g", 
lastrow=klass, pivotrow=klass, mehr...})prototype.js (Zeile 824)
_reloadFolders()dimpbase.js (Zeile 3151)
toggleSubscribed()dimpbase.js (Zeile 3141)
contextOnClick(parentfunc=function(), e=dataavailable )dimpbase.js (Zeile 971)
bind()prototype.js (Zeile 391)
wrap()prototype.js (Zeile 429)
bindAsEventListener(event=dataavailable )prototype.js (Zeile 399)
responder(event=dataavailable )prototype.js (Zeile 5575)
fire(element=span#anonymous_element_5.iconImg, 
eventName="ContextSensitive:click", memo=Object { 
elt=a#ctx_folderopts_sub, trigger="ctx_folderopts"}, 
bubble=true)prototype.js (Zeile 5734)
_methodized()prototype.js (Zeile 438)
_leftClickHandler(e=click clientX=115, clientY=505)contex...tive.js 
(Zeile 196)
bindAsEventListener(event=click clientX=115, clientY=505)prototype.js 
(Zeile 399)
responder()prototype.js (Zeile 5598)
event = click clientX=115, clientY=505

Still not seeing this.  On either master or develop.

Ways I tried to reproduce:

1. Select message in subscribed mailbox.
2. Show All mailboxes
3. Verify you can still reply to message.
4. Hide unsubscribed
5. Verify you can still reply to message (or any other message in mailbox).

Also:

1. Show All mailboxes
2. Open unsubscribed mailbox
3. Select message.
4. Hide unsubscribed
5. Verify you can still reply to message (or any other message in mailbox).

I experienced this again and tracked it further down. After displaying 
and then hiding unsubscribed folders, I noticed that the reply button 
doesn't work because no message is considered selected anymore, see 
comment 6.
This happens because in ViewPort::_getBuffer() a new ViewPort_Buffer 
is created, because this.views is an empty hash.

Closing as fixed until/unless it can reliably be reproduced.

Could be a duplicate of Bug #10886.

Changes have been made in Git for this ticket:

Bug #10769: Explicitly catch exceptions in critical viewport methods
In methods that set isbusy, we need to catch exceptions so that we can
reset the value of isbusy, or else viewport requests will enter an
infinite loop.

  1 files changed, 33 insertions(+), 14 deletions(-)
http://git.horde.org/horde-git/-/commit/e8677baa513291c0d577d5ba675472dca5862ee0

The mailbox is unresponsive because ViewPort.isbusy is being set to 
true, but the code is crashing before it can be set back to false.   
Thus all other calls to ViewPort are entering infinite loops because 
they are waiting isbusy to return to being false.

I've hesitated putting try/catch() statements around these calls 
because it may leave the viewport in an incorrect state and, IIRC, 
errors in the try/catch statement will not bubble up to tools like 
firebug.  Although in the latter case, I think that we can re-throw 
the exception and this will fix that issue.

But the underlying issue needs to be debugged on the server where it 
is seen.  So you'll have to catch this in the future and poke around 
to discover the issue.

The symptoms are a bit different though. The message is still 
highlighted (from before showing all folders), but it's not marked as 
selected internally, i.e. the preview is not displayed, and if I try 
to drag the message, it says "0 messages..." again. I cannot select 
any other message either.

This just happened again, but this time I got a JS error. 
Unfortunately (or fortunately, give my earlier experience) Firebug was 
not running, so I don't have a backtrace:

Fehler: vs.get("dataob").first() is undefined
Quelldatei: http://neo.wg.de/headhorde/imp/js/dimpbase.js
Zeile: 3287

Rejecting - I can't reproduce on either of my computers, nor on various VMs.

Can't reproduce.  And that just sounds like a browser/OS issue.  If a 
snippet of IMP code triggers issues in the javascript engine, that's 
still a FF problem, not ours.

There are more whacky things going on. For example I can select 
multiple messages, and they are highlighted correctly, but when I try 
to drag them, it says "0 messages...".

I'm not sure if this is a browser issue or a bug in IMP. But once I 
select to show all folders in the "Other Actions" popdown, I can no 
longer open a reply window to a message that worked before just fine. 
Trying to track this down with Firebug crashed the browser completely, 
so I'm not sure if this isn't some internal problem instead. FF 7.0.1.