211495 - Make Junk button also move to next mail

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[Ben Bucksch (:BenB)]

Reproduction:
- Disable delete/move when marked as junk
- Open a Junk message
- Press the Junk button on the toolbar (not in the junk row of the thread pane)

Actual result:
- Message marked as junk
- nothing else

Expected result:
- Message marked as junk
- Next message is displayed, act like the Delete button in that it closes
the message and opens the next one. "Next message" excludes messages identified
as junk (same should be true for Delete, BTW).

Comment 1

[Ben Bucksch (:BenB)]

compare bug 209748.

Comment 2

[Scott MacGregor]

I personally don't think it should do this. Toggling the junk status should not
have any effect on selection. 

Comment 3

[Ben Bucksch (:BenB)]

OK, but why? I am unlikely to want to further read the spam or do anything else
with it, or am I?

Comment 4

[R.K.Aa.]

The next message may also be spam, and you may not want to load it - several
bugs about that.

Comment 5

[Mike Cowperthwaite]

There is the option existed for Mozilla to automatically move mail to Junk (or 
Trash) when manually marked as junk.  With that feature turned on, the Junk 
button (and also the J hotkey, new since this bug was opened) *do* advance the 
selection (altho mail already marked as Junk is not skipped in the process of 
advancing -- bug 262636 is the only one I can find about this problem).

As a justification for Scott's comment 2:  Without that feature enabled, the 
behavior of J or the Junk tool is similar to the behavior of M or the Mark tool 
to toggle the message's Read status.

Ben, do you still want to keep this rfe open?

Comment 6

[Ben Bucksch (:BenB)]

Yes, IMHO, the "toggle" idea doesn't make sense to me, as comment 3 says.

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420