64772 - toolbar "Mark -> All Read" marks current news message as unread

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Andreas Premstaller]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20010108
BuildID:    2001010804

Using the "As read->All read"-command on the toolbar, the currently selected
news message is marked as Unread. All other messages in the newsgroup are
correctly marked as read. This problem does not appear if you use the menu
"Message->Mark->All read".

Reproducible: Always
Steps to Reproduce:
1. Open a news group, select any message
2. Status of this message turns to "Read"
3. On the toolbar, select "As Read->All Read"

Actual Results:  The selected message is marked "Unread". All other messages are
marked "Read".

Expected Results:  All the messages in the newsgroup, including the current one,
are marked "Read".

This happens only if you use the toolbar-command. It works correctly using the
menu "Message->Mark->All Read"

Comment 1

[Keyser Sose]

*** This bug has been marked as a duplicate of 64326 ***

Comment 2

[Andreas Premstaller]

Reopening. This bug is not about whether or not the read-attribute is toggled
when selecting "mark as read".
 It deals with a different behaviour of the same command (Mark->All Read)
depending on whether it is activated via the menu (Message->Mark->All read,
works correctly) or via the toolbar icon Mark->All Read.
Furthermore, regardless whether the current message is marked Read or Not Read,
after the toolbar command "Mark-> all *read*", it is always marked *Unread*
(which is plain wrong). 

Comment 3

[[e-mail]]

To fix this bug remove the observes from line 1082 of mailWindowOverlay.xul

Comment 4

[[e-mail] (gone - use [e-mail] instead)]

Blake, Timeless is this a simple thing for either of you to correct?

Comment 5

[(not reading, please use [e-mail] instead)]

accepting.  I'll try out what neil suggests.

Comment 6

[[e-mail]]

Sorry, removing the observer only fixes the menu, I think you also need to add
buttonaction="goDoCommand('cmd_markAsRead')"
N.B. I don't know what will happen if the command is unavailable.

Comment 7

[[e-mail]]

Another way is to ask skin authors to make dual menubutton buttons inherit the
observer attribute from the buttonobserver attribute (as with buttonaction and
buttontooltiptext). Then you can simply rename the observer attribute to
buttonobserver in the dual menubutton. Using this method clicking the button
does toggle the read mark. The button still doesn't disable when the menu does :-(

Comment 8

[[e-mail]]

Sorry, that last comment is wrong, anonymous content cannot inherit observers.

Comment 9

[[e-mail]]

My latest suggestion: change line 1085 of mailWindowOverlay.xul:
<menupopup ... oncommand="event.preventBubble()">

The disadvantage of this method is that you can only use the toolbar to mark all
read if a message is already selected.

Comment 10

[Andreas Premstaller]

There is more strange behaviour about the Mark-button. Here is a comparison of
what actions the single items of the Message->Mark-menu and of the Mark-toolbar
button call:

Command         Menu Message->Mark>             | Toolbar Mark>
------------------------------------------------------------------------------
As Read         Toggle read status (bug #64326) | nothing (bug #64242)
                                                |
Thread As Read  Mark all messages in the        | Mark all messages in the
                selected thread as read         | selected thread as read
                                                | except for the currently 
                                                | selected message that is
                                                | always marked as unread.
                                                |
All Read        Mark all messages in the        | Mark all messages in the 
                current newsgroup as read       | newsgroup as read except 
                                                | for the currently selected
                                                | message that is always 
                                                | marked as unread.
                                                | 
Flag            Toggle Flag-attribute           | Toggle Flag-attribute
                Leave read-status unaltered     | Toggle read-status

Analysis:
The common cause for all the strange behaviour using the Mark>-commands in the
toolbar seems to be that *after* the execution of the correct command the
read-status of the current message is once more toggled. 

So, the selected "Mark>As Read" toggles the read-status once, and the second
toggle (that would always be called, I don't know why) toggles read-status back
to original, viola, bug #64242.

Similarly, "Mark Thread As/All Read" first executes the right command, marking
all messages as read, and than toggles the status of the current message to unread.

Flag, well, explains itself.

Comment 11

[Mike Pinkerton (not reading bugmail)]

*** Bug 66981 has been marked as a duplicate of this bug. ***

Comment 12

[Andreas Premstaller]

From bug 66548:
------- Additional Comments From [e-mail] 2001-01-25 10:32 -------

It's a front end problem - if you do a mark all read, it does a mark all read
command, but also does a mark messages read command, which toggles the mark
readness of the current selection. here's the stack trace:

nsNewsDatabase::SetHdrReadFlag(nsIMsgDBHdr * 0x08b07d80, int 0x00000000) line 379
nsMsgDatabase::MarkHdrReadInDB(nsIMsgDBHdr * 0x08b07d80, int 0x00000000,
nsIDBChangeListener * 0x00000000) line 1585
nsMsgDatabase::MarkHdrRead(nsMsgDatabase * const 0x08ed2310, nsIMsgDBHdr *
0x08b07d80, int 0x00000000, nsIDBChangeListener * 0x00000000) line 1861 + 26 bytes
nsMsgDatabase::MarkRead(nsMsgDatabase * const 0x08ed2310, unsigned int
0x00002a31, int 0x00000000, nsIDBChangeListener * 0x00000000) line 1603 + 29 bytes
nsMsgHdr::MarkRead(nsMsgHdr * const 0x08b07d80, int 0x00000000) line 232 + 31 bytes
nsMessage::MarkRead(nsMessage * const 0x08b01d14, int 0x00000000) line 342 + 30
bytes
nsMsgFolder::MarkMessagesRead(nsMsgFolder * const 0x028a35ac, nsISupportsArray *
0x06657330, int 0x00000000) line 2100 + 27 bytes
nsMsgMessageDataSource::DoMarkMessagesRead(nsISupportsArray * 0x066576b0, int
0x00000000) line 1939
nsMsgMessageDataSource::DoCommand(nsMsgMessageDataSource * const 0x04c63f20,
nsISupportsArray * 0x066576b0, nsIRDFResource * 0x04c719e0, nsISupportsArray *
0x00000000) line 725 + 14 bytes
CompositeDataSourceImpl::DoCommand(CompositeDataSourceImpl * const 0x04b99510,
nsISupportsArray * 0x066576b0, nsIRDFResource * 0x04c719e0, nsISupportsArray *
0x00000000) line 1329 + 24 bytes

It might be a problem with the mark button, or some problem in the js code.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 66548 has been marked as a duplicate of this bug. ***

Comment 14

[[e-mail]]

Of course it does a mark message read. The mark all read menuitem's oncommand
event is bubbling up to the menubutton which is observing cmd_MarkAsRead.
The first alternative is to stop the event bubbling. The easiest place to do
this is in the menupopup.
The second alternative is to code the buttonaction handler in the menubutton
instead of using the observer. This allows you to mark all read without
selecting a message in the same manner as Communicator. Unfortunately clicking
the button then has no effect :-(
The third alternative is for Mozilla to abandon menubuttons and revert to
separate menu and button controls (the File button used to work like this).

Comment 15

[(not reading, please use [e-mail] instead)]

fixed.

Comment 16

[[e-mail]]

Somewhat overkill, though, surely? (I still think it should be done in the popup).

Comment 17

[(not reading, please use [e-mail] instead)]

neil, give me a patch.

Comment 18

[(not reading, please use [e-mail] instead)]

oops, I meant to say:

neil, if you have a better fix, please elaborate (or provide a patch).

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

VERIFIED FIXED - Mac 2001020204, Linux 2001020208 and Windows NT 2001020204.

NOTE: If Neil has a better patch, I can wait to mark this VERIFIED until it's
checked into the tree.

Comment 20

[[e-mail] (gone - use [e-mail] instead)]

Marking VERIFIED.  Neil you can re-open this or file a new bug if you have a
patch you want to commit.  Thanks.

Comment 21

[[e-mail]]

Attachment: Patch for alternative prevention of event bubbling.