I'm going to close this ticket.  Re: duplicate notifications - as 
discussed below, this is a limitation of the current Notification 
system.  Will add a new Enhancement ticket to track this.

This is fixed now.

Fixed.  That's just a cosmetic error - it doesn't break anything.

Changes have been made in Git for this ticket:

Bug #9950: Fix undefined error

  1 files changed, 0 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/71215a4e0f57a15614556de24efc5f7f20d7c442

with this patch, I get the following errors :
NOTICE: HORDE [imp] PHP ERROR: Undefined variable: status [pid 26255 
on line 279 of "/var/www/html/hordetest/imp/compose-dimp.php

Ping - at least on this fix?

Hopefully these new fixes work better.  Also fixed the message popup window.

Changes have been made in Git for this ticket:

Bug #9950: Fix notifications in dimp popup screens

  4 files changed, 6 insertions(+), 1 deletions(-)
http://git.horde.org/horde-git/-/commit/1e9e1316ee5f730cd724f13ed215098e5686475b

I think this issue is more of a fundamental flaw (or, at least, a 
limitation) in the current Notification system.  At present, there 
really is no way to push a notification with the intent of "I want the 
notification to be displayed on this page access and, if not, you can 
go ahead and discard the notification".  Especially for things like 
newmail notifications, this is time-critical information.  It becomes 
useless once the page access is complete.

I've worked around the limitation in IMP (somewhat) by using 
Decorators.  Decorators were used simply because they are triggered 
whenever notify() is called.  Thus, I only create notifications if I 
know the notifications are about to be displayed.

However, an alternative method would be to indicate, at the time we 
are pushing the notification, whether the notification should persist 
in the session.  (Although an advantage of doing the Decorator 
approach is to prevent potentially costly activities, such as mailbox 
polling, when there is absolutely no chance it would be used on a page).

Actually not quite yet. The sound notifications are now output between 
the head and body tags.

And they are raised several times if you had several notifications 
piling up. Though this might be a problem of audio notifications not 
being used in the main interface. It makes them pile up, and they are 
all outputed at once (making a terrible noise) if you open a page that 
supports audio notifications. I'm not sure if we should implement a 
duplicate check in the audio notification listener. But for now we 
should either support audio notifications throughout DIMP or check for 
duplicates where we output the notifications in DIMP.

Yes

Does this fix what you were seeing?

Changes have been made in Git for this ticket:

Bug #9950: Fix notifications in compose window (dynamic view)

  1 files changed, 4 insertions(+), 0 deletions(-)
http://git.horde.org/horde-git/-/commit/d24291a4c369b4a81a04c01541026acce6e823a0

If opening the compose window triggers a notification, this 
notification isn't displayed anywhere. If that notification contains 
audio, the audio tag is printed before starting the page output. 
Commit fdd357ede9d2452c6db34f8a6282d456cfb9402c was supposed to fix 
that, but it broke other things.