180203 - [mailviews] junk mail appears in not junk view

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

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

[mailviews] junk mail appears in not junk view (feels like a general view issue)

1) view your inbox on the "not junk" view
2) new mail arrives, get's classified
3) if it gets classified as junk, it shows up in the "not junk" view

same thing goes for unread message in the "unread" view.

when marked as read, they should probably disappear from the view.

or is it working as designed?

Comment 1

[jglick]

We probably don't want messages disappearing as the user is clicking on them. 
For example, user clicks the green star (to toggle the msg to read) and the msg 
(poof) is gone.  Or the user clicks on the junk mail column cycler and the msg 
disappears.

We should update the thread pane on refresh though. So, the user clicks "Gets 
Msgs" or changes folders, anything and causes a refresh, msgs that need to be 
added or removed from the current view should happen. 

Question: if biff is triggered at intervals based on prefs, does that count as a 
refresh? I'd say if the msgs are automatically downloaded, via pref (pop) or 
auto (imap) that counts as Refresh. But just the indicator that new msgs are 
avail but not pulled (pop), doesn't count as Refresh.

Comment 2

[laurel]

I think with the Not Junk view, which will be a very visible view to advertise
the junk mail feature, we should not show the incoming classified as junk mail.
 This is an automatic feature to classify, whereas the scenario of reading a
message in Unread is usually a manual user intiated action.

(Side issue, will log a bug: I also think the view should persist across
sessions, particularly now with the Not Junk view.  If the user were to open
mail to a Not Junk view then have to refresh just to get that view it would be
cumbersome.)

Comment 3

[Quinn Yost (mythdraug)]

This is an issue for any header which can be changed on a message (read, junk,
label, flag, etc.)

Comment 4

[Frank Harper]

If the user has the Not Junk view activated, then junk mail should never even
appear.

Comment 5

[Scott MacGregor]

The problem is that the automatic classification happens after the mail arrives.
When you are in a mail view, as new mail arrives, we check to see if should be
visible in the current view. In this case, we haven't marked it as junk yet so
it shows up in the view. Then the junk mail controls kick in and classify it as
junk, but it is still in the view. 

One possible work around could be to refresh the mail view after a batch of
messages have been run through the junk mail control. Only do it when we are
automatically looking for junk as opposed to when the user toggles the junk icon
for a message. Or is that inconsistent?

Comment 6

[jglick]

1. View = Not Junk. New mail comes in. Ideally, we would like to identify junk 
mail first and not ever display the Junk mail in this View. (as mscott mentions, 
this might be tricky).

2. View = Not Junk. New mail comes in. User manually marks a msg as Junk. 
Message shouldn't automatically disappear from the View. On Refresh though, see 
comment #1, the msg marked as junk would get removed from the View.

Comment 7

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 8

[[e-mail]]

Is it possible to run filters on messages as the headers are loaded?

Comment 9

[esther]

Current behavior is 20030326 macosx, linux and winxp: 
1. View = Not Junk
2. New Junk Mail comes in, not yet analyzed.
3. Analyzing starts, now some of the messages are marked as Junk
Note: If option to automatically move JUNK mail is ON
4. When analyzing is done, junk mail moves to Junk Folder.
Note: If option to automatically move JUNK mail is OFF 
5. When analyzind is done, junk mail stays in view until user changes folders,
getting new messages doesn't remove the junk mail from view nor does Biffing
even if user get new Junk mail prompting the action to mark incoming junk mail.

Expected: per Jen's comment Refresh of folder by Biff, Get Msg or switching
folders should refresh the view.  It's not happening for Get Msg or Biff.

Comment 10

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

aiming for 1.4 final

Comment 11

[David :Bienvenu]

I think this should probably be special-cased for the junk flag, and I
definitely don't think biff or even get new mail should cause the view to get
refreshed. I don't know how hard it would be to special case the junk flag and
the junk view, however.

Comment 12

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

I bet the same thing happens for message I mark as read, when in the unread view.

Comment 13

[David :Bienvenu]

I think we should try to fix it so that we remove newly automatically 
classified junk mail from the non-junk view, but NOT remove read mail from 
unread mail only view when the user reads it, or any of the other suggestions. 
Junk mail is really a special case because we classify after creating the view.

Comment 14

[David :Bienvenu]

taking, proposed fix coming up.

Comment 15

[David :Bienvenu]

Attachment: proposed fix

this patch overrides ::OnKeyChange for quick search to try to detect the case
that a new message has been classified as junk by a plugin. If this happens, we
see if the new hdr matches our search criteria - if it doesn't, we remove it
from the view. I'm trying to test this patch, but I don't have any junk mail
coming in. It doesn't seem to have any ill effects so far, anyway.

Comment 16

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

Comment on attachment 123444 [details] [diff] [review]
proposed fix

r/sr/a=sspitzer

gave bienvenu some style nits over aim, which he said he'd fix locally before
checking

Comment 17

[David :Bienvenu]

Attachment: second part of fix

I also need the manual marking of messages to set the origin first, then the
junk score, so that the quick search code will know that the manual marking
origin is not the plugin, so it won't remove the message from the view.

Comment 18

[David :Bienvenu]

fix checked in.

Comment 19

[esther]

Using trunk build 20030519 on winxp, macosx and linux and the test case in
comment #9 this is fixed and verified.  Incoming messages analyzed as junk are
removed from the view immediately after they are analyzed.