Closed Bug 132622 Opened 22 years ago Closed 21 years ago

Collapsed thread should not be underlined after "Mark thread as read"

Categories

(SeaMonkey :: MailNews: Message Display, defect)

defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 74835

People

(Reporter: mg8, Assigned: racham)

Details

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.9+) Gecko/20020319
BuildID:    2002031908

Threads containing read and unread articles are marked as underlined. When I now
collapse the thread and choose Messages -> Mark -> Mark thread as read", I would
expect the underlinement to disappear. This is infact happening when I open and
collapse the thread again.

Reproducible: Always
Steps to Reproduce:
1. Open a thread.
2. Read some, but not all, articles of it.
3. Collapse the thread.
4. Choose Message -> Mark -> Mark thread as read.

Actual Results:  collapsed thread is still underlined

Expected Results:  collapsed thread should not be underlined
Summary: Collapsed thread should not be underlines after "Mark thread as read" → Collapsed thread should not be underlined after "Mark thread as read"
This also happens if you read all the messages in the thread. I'm seeing the
same problem with a trunk build from 4/28 (Build ID: 2002042801) and with a 1.0
RC1 build from 4/26 (Build ID: 2002042609) on Linux. I've several threads in
different newsgroups (netscape.public.mozilla.general, de.comm.software.mozilla)
that show this behavior.
QA Contact: nbaca → stephend
Confirming with a branch build - 2002-05-06-06, Windows 2000.
Status: UNCONFIRMED → NEW
Component: Account Manager → Mail Window Front End
Ever confirmed: true
confirming with moz build 2002102814 1.2b, Win XP.

maybe time to change severity to minor instead of trivial?
and all systems instead of macintosh?
linux confirmed?
I can confirm this on Linux too as of:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021126

I studied the problem a bit more and noticed that this is actually a repaint
problem. I was to fill a bug raport of the issue that shortcut "r" won't change
the status of the collapsed thread until I move to next message/thread, when I
found this bug report. After reading the description of this bug I noticed that
if I use the "Message -> Mark -> Thread As Read" menu selection and the menu
went partially over the collapsed thread entry the icon and subject field were
repainted, but Sender, Date, and Status field were not. Further studies by
putting another window over the Mail&Newsgroup window or minimizing the
Mail&Newsgroup window and then restoring it back to front concluded that this
definedly is a repaint problem.

To see this do following:
1) go to a collapsed thread
2) press r
3) nothing seems to happen (looks like status has not changed to "read")
4) minimize the Mail&News Window or put another window over the collapsed thread
line
5) restore the Mail&News Window to front on screen
6) status is also shown to be changed to "read" as the entry has been repainted

Further notifications:
The problem is also seen if the whole newsgroup is marked as read either using
"Message -> Mark -> All Read" menu or Ctrl-Shift-C keyboard shortcut. BUT it is
not seen if pop-up menu's "Mark newsgroup read" selection in the
Folder/Newsgroup pane is used.
OS: Mac System 9.x → All
Hardware: Macintosh → All
Attached patch proposed patchSplinter Review
After marking the messages as read in nsMsgDatabase::MarkHdrReadInDB it
broadcasts a notification about it to all listeners.

One of the recipients is nsMsgDBView::OnKeyChange. One of the parameters is the
key of the message whose flags have been changed.
This key gets translated to the index of the message in the current view then.
If the concerning message is in the view (not in a collapsed thread), the view
flags for it getting changed and the UI will be noted about it to redraw.

After this the key is translated to the index of the thread in the current
view.
If the concerning thread is in the view, UI will be noted to redraw it too.

The point is, that this thread index only gets computed and its view redrawed
if one of the messages set to unread, is in the current view (type "m" while on
the top message of the collapsed thread and then mark thread as read - you'll
see that everything's fine)!


I now moved the codelines for the second notify out of the "if message is in
view" and that's it.

What I don't like is, that this notify will be send out, every time one of the
messages gets tested if in view. That's nothing very new, as this is what
happened (and happens) if the thread is going to be marked as read while it's
expanded.
But maybe this behaviour should get adjusted so that only one notify at the end
of the "mark as unread"-loop gets send out.
Attachment #118874 - Flags: review?(neil)
Comment on attachment 118874 [details] [diff] [review]
proposed patch

Yes, I agree, you need to update the thread index even if the thread is
collapsed.

Would you mind fixing the code not to note the change when the message is the
first in the thread? An extra check for threadIndex != index should do the
trick.
Attachment #118874 - Flags: review?(neil) → review-
Please put further patches in bug 74835, thanks.

*** This bug has been marked as a duplicate of 74835 ***
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
Verified dup
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: