Closed Bug 189911 Opened 22 years ago Closed 18 years ago

"empty junk" menu entry in context-menu of junk-folder

Categories

(MailNews Core :: Backend, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: darkshadow, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: polish)

Attachments

(2 files, 2 obsolete files)

It's nearly the same than "empty trash" in the context menu of the trash folder.

The idea is that I only use the junk folder to verify that these mails are
really junk (one time a private mail was accidently marked as junk...) and
delete them afterwards. So an option to remove all mails from this folder
would be nice.

If you think it's a low priority feature I'd like to work on it, as I suppose
it's easy to implement and there already exists nearly all necessary code due
to the "empty trash" feature.
This would be my first non-string-change patch for Mozilla, so if there is
someone who is familiar with that code and maybe has some time I's be very
glad, but first I'll try to fail on my own ;)
Nice idea. Adding me to the CC list. ;)
This is simple to implement, sensible and useful :)

I'd rate it P4
While looking at the code a question occured to me:
Why is "Trash" in nsLocalMailFolder.cpp, Line 308
[http://lxr.mozilla.org/seamonkey/source/mailnews/local/src/nsLocalMailFolder.cpp#308]
hardcoded? Is there a special reason for it, or is it a bug?
It does make sense, the same way that in the File menu there is also an "Empty
Trash". It's just logical to have both of these folders have similar
functionality since the logic behind them is "I'm storing messages there before
deciding to definitely get rid of them".

So both "context menu" for Junk folder, AND "Empty Junk" in the mailer's File menu.
dup me.
Assignee: mscott → sspitzer
Wouldn't it be much better to have a general "Empty Junk" entry beneath "Empty
Trash" in the File menu instead?
Perhaps the action associated with such a context menu can include bug 195605. 

That bug states that right now when Junk is deleted [either "automatically after
xx days "or via delete] the junk messages aren't deleted but go to TRASH.

So pressing EMPTY JUNK in a context menu basically should be a 
1) "MOVE JUNK TO TRASH" [which needs to be followed by an "EMPTY TRASH"]
or 
2) "EMPTY JUNK" which removes junk directly
*** Bug 199676 has been marked as a duplicate of this bug. ***
I agree that it  should be very similar to the empty trash feature.  Ideally,
I'd like to see a right click menu item after highlighting the junk folder.  The
other approach, would be to be able to empty junk folder without highlighting it
or using the autodelete.  
*** Bug 211033 has been marked as a duplicate of this bug. ***
See also bug 157423 that asks for having "empty folder" for all available folders.
*** Bug 216650 has been marked as a duplicate of this bug. ***
*** Bug 216887 has been marked as a duplicate of this bug. ***
A must-have for thunderbird as well...
*** Bug 220683 has been marked as a duplicate of this bug. ***
*** Bug 222531 has been marked as a duplicate of this bug. ***
*** Bug 224460 has been marked as a duplicate of this bug. ***
*** Bug 229517 has been marked as a duplicate of this bug. ***
*** Bug 232637 has been marked as a duplicate of this bug. ***
I've used another email application for years, and the "empty junk mailbox"
entry was both in the main menu (near empty trash) and in the context menu.

Both are useful :
-main entry, when you've got lots of mailboxes, you don't want to look for junk
mailbox ;
-context entry, when you've just checked there was no false positive junk mail,
and want to get rid of all the junk.

As the messages are junk, and are known to be junk, I see no point in moving
them from junk mailbox to trash instead of just deleting them.
There is an extension which almost does what is suggested it here.
Delete Junk Context Menu. See http://forums.mozillazine.org/viewtopic.php?t=56397
Great extension! I'd think, from all the chatter here, that this would,
hopefully, get wrapped into the core code too.

(In reply to comment #21)
> There is an extension which almost does what is suggested it here.
> Delete Junk Context Menu. See http://forums.mozillazine.org/viewtopic.php?t=56397

I do not think that this is "great", since Mozilla does not mark all trash and
maybe some people have additional spam-filter-programms that generate header
additionals which causes the marked mails to be moved to the spam folder by a
mozilla filter setup.
I don't want to delete 50% of my spam e-mails myself.

So I think the only "great" solution is a "clean spam folder" item.

It's only a menu item to implement....
I just noticed that this DOESN'T delete the junk mail. It only moves it into the
 Trash folder so you still have to empty the trash folder. So its good, not
great. :-)

(In reply to comment #22)
> Great extension! I'd think, from all the chatter here, that this would,
> hopefully, get wrapped into the core code too.
> 
> (In reply to comment #21)
> > There is an extension which almost does what is suggested it here.
> > Delete Junk Context Menu. See
http://forums.mozillazine.org/viewtopic.php?t=56397
> 
> 

(In reply to comment #24)
> I just noticed that this DOESN'T delete the junk mail. It only moves it into the
>  Trash folder so you still have to empty the trash folder. So its good, not
> great. :-)

If you go to the options of the extension you can tell it to bypass the trash.

(In reply to comment #23)
> I do not think that this is "great", since Mozilla does not mark all trash and
> maybe some people have additional spam-filter-programms that generate header
> additionals which causes the marked mails to be moved to the spam folder by a
> mozilla filter setup.
> I don't want to delete 50% of my spam e-mails myself.

Yes this is indeed unfortunate

> So I think the only "great" solution is a "clean spam folder" item.
> 
> It's only a menu item to implement....

I took a look at doing it before I discovered the extension I mentioned. I then
found that Empty Trash code is spread over quite some files, so I found
implementing Empty Junk quite daunting. The code of the extension is not that
difficult, but finding out what you now should add / change things in the
mozilla code seems not that easy for somebody not to familiar with the mozilla
code. 
*** Bug 244274 has been marked as a duplicate of this bug. ***
*** Bug 260207 has been marked as a duplicate of this bug. ***
*** Bug 237380 has been marked as a duplicate of this bug. ***
*** Bug 264402 has been marked as a duplicate of this bug. ***
I think that 261875 is a duplicate of this one.

I'd like to repeat my earlier request for this feature, or the nearly equivalent
idea of automatically moving the contents of 'junk' to the trash folder on exit.

Whatever, there needs to be a simple way of getting junk to go away completely.

This idea has been around for more than long enough.  Is anything going to
happen about it? or is something else planned for the future?
Product: MailNews → Core
I realize the majority of this may have been said before but after reading
several entries this is what I have come across

> Add right click menu to delete junk
> Add right click menu to move junk to trash (which can be emptied on exit)
> Add top menu button to delete junk.

This I don't know if it has been said, but is what I am looking for...A settings
option to just delete junk on exit just as trash is. Heck, if i dont need it in
my inbox, i dont need it in my trash!
Blocks: 261875
I've been using 1.0 for a while now, and have tools - junk mail controls  set to
"delete after 14 days" from the junk mail folder.  I could, alternatively, have
had the junk put straight in the trash from the same menu item.

As far as I am concerned that is functionally equivalent to fixing my original
bug 232637, and therefore this one.  I don't suppose everyone agrees, but since
I no longer have to delete by hand as far as I am concerned this has become
irrelevant and could legitimately be closed.  I no longer believe the product
needs changing for this.
Being that the extension I commented on earlier in this bug was apparently
rolled into the main code, I'd have to agree with Robert Harvey, and this
bug/enhancement could be closed. 
(In reply to comment #33)
> Being that the extension I commented on earlier in this bug was apparently
> rolled into the main code, I'd have to agree with Robert Harvey, and this
> bug/enhancement could be closed. 

Did that extension roll into the code?? I don't see it and I guess then there
should be patch attached to this bug. The behaviour Robert Harvey is describing
is already for quite some time present in TB. It's at least in 0.9 and I think
also already way earlier.

I for one would like to see an Empty Junk item, because I receive around 100
spam mails a day and always skim over them to see if there wasn't an occassional
error with the junk notification (it's rare but it happens). If there are no
real mails I delete all the junk mails.

With the approach of Robert Harvey I will have 1500 mails in my junk mail folder
and have to remember which one I already skimmed over.
(In reply to comment #34)

> I for one would like to see an Empty Junk item, because I receive around 100
> spam mails a day and always skim over them to see if there wasn't an occassional
> error with the junk notification (it's rare but it happens). If there are no
> real mails I delete all the junk mails.
> 
> With the approach of Robert Harvey I will have 1500 mails in my junk mail folder
> and have to remember which one I already skimmed over.

i strongly agree whit this analysis, i'm in the exactly same situation, and i
think many Mozilla / Thinderbird users are in the same situation. I think that
an "Empty Junk" contextual menu item would be very useful.

 
(In reply to comment #35)

Don't close this feature request. I receive about 100 to 2.500 Junk mails per
day and it is rather dangerous to let the Junk control push them to the Trash
bin directly. In the Trash bin I also find manually deleted Junk and non-Junk stuff.

It is much smarter to have automatically Junk-declared stuff in the Junk folder
and review this from time to time. Then I drop the reviewed Junk stuff to the
Trash bin myself.

Today, I use the Windows shortcut [Alt][T][E] for "Tools: Delete Mail Marked as
Junk in Folder" for dropping the reviewed Junk stuff to the Trash bin.

Then I clear the Trash bin with [Alt][F][Y] ("File: Empty Trash").

TEFY makes my daily Junk review work much faster, but as I cannot see these
shortcuts in the MacOS X version of Mozilla, I would rather prefer to have the
"Empty Junk folder" menu entry, too.
*** Bug 261875 has been marked as a duplicate of this bug. ***
*** Bug 288621 has been marked as a duplicate of this bug. ***
*** Bug 320613 has been marked as a duplicate of this bug. ***
*** Bug 321917 has been marked as a duplicate of this bug. ***
As TB2 is a premary UI polish release nominating for TB2.
Flags: blocking-thunderbird2?
*** Bug 336757 has been marked as a duplicate of this bug. ***
(In reply to comment #25)
> (In reply to comment #24)
> > I just noticed that this DOESN'T delete the junk mail. It only moves it into the
> >  Trash folder so you still have to empty the trash folder. So its good, not
> > great. :-)
> 
> If you go to the options of the extension you can tell it to bypass the trash.

Personally I'd prefer this behaviour (Move to trash per default and a (hidden?) pref to bypass the trash). I suppose, that most people expect, that eMails are always moved to the trash before finally deleting them from the trash.

An 'Empty this folder' context menu entry for all folders is not necessary. It would just useless clutter and may confuse people. Junk is something, like a secondary trash folder im my eyes.

Regards,
  Christian Stadler
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Keywords: helpwanted
*** Bug 354724 has been marked as a duplicate of this bug. ***
We're collecting dupes on this feature request which grows a beard since 2003 already. Will I ever see this tiny enhancement come true or rather continue receiving mails which inform me about more dupes on this request?

Who do I have to kill ... ? ;-)
This must be done! I get more that 160+ as junk everyday and I am sucked moving those junks to trash and kill it then.

This are too much actions and if Thunderbird will be better than Outlook(/express) and it's derivates, this needs to be coded asap and available on next update.
Attached patch Patch rev. 1 (obsolete) — Splinter Review
Assignee: sspitzer → mats.palmgren
Status: NEW → ASSIGNED
Attachment #252613 - Flags: superreview?(bienvenu)
Attachment #252613 - Flags: review?(bienvenu)
Thx for the patch, Mats. One potential problem - I don't think you can go through the view to delete all messages - the folder that you do a delete all junk from might not be selected. I.e., you could just right click on the junk folder when an other folder is actually selected. I think you need to open the db, list all the keys, and then delete them, which is fairly simple.
Would it be possible to add a confirmation dialog? (With an always ask me checkbox.)
Comment on attachment 252613 [details] [diff] [review]
Patch rev. 1

minusing because the context menu doesn't always operate on the tree view.
Attachment #252613 - Flags: superreview?(bienvenu)
Attachment #252613 - Flags: superreview-
Attachment #252613 - Flags: review?(bienvenu)
Attachment #252613 - Flags: review-
Attached patch Patch rev. 2 (obsolete) — Splinter Review
Attachment #252613 - Attachment is obsolete: true
Attachment #252672 - Flags: superreview?(bienvenu)
Attachment #252672 - Flags: review?(bienvenu)
Thx for the new patch, Mats! I'd question the need for a confirmation dialog. Do we have one for Empty Trash? I'm also unclear on the need to handle sub-folders although I guess it doesn't hurt, other than a bit of code bloat...do users really have sub-folders of Junk?
(In reply to comment #54)
> I'd question the need for a confirmation dialog.

The operation cannot be undone.

> Do we have one for Empty Trash?

No, but we probably should have one since it also cannot be undone.
I wrote confirmToProceed() with this in mind, so you could use it
as confirmToProceed('emptyTrash')...  ;-)

> I'm also unclear on the need to handle
> sub-folders although I guess it doesn't hurt, other than a bit of code
> bloat...do users really have sub-folders of Junk?

"Empty Trash" removes subfolders so I think we should do it for symmetry.
Comment on attachment 252672 [details] [diff] [review]
Patch rev. 2

OK, thx for the patch, but please change keyword to taskName or commandName or something to avoid confusion with keyword/tags
Attachment #252672 - Flags: superreview?(bienvenu)
Attachment #252672 - Flags: superreview+
Attachment #252672 - Flags: review?(bienvenu)
Attachment #252672 - Flags: review+
Bug 179891 requests confirmation for Empty Trash.
I'm not particularity happy with the wording. For reference, 

outlook:
Are you sure you want to permanently delete all the items and subfolders 
 in the "Junk-E-mail" folder? [Yes] [No]
Are you sure you want to permanently delete all the items and subfolders 
 in the "Deleted Items" folder? [Yes] [No]

"items" is a bit odd, but with items -> messages it's about what I would like to see.

And while I'm at it, doesn't usability studies say to use positive sentences with checkboxes - easier to grasp "always ask me" vs. "don't ask me".
The patch didn't add a default pref value, BTW.

But other than that, great job. Seriously:)
Attached patch Patch rev. 3Splinter Review
(In reply to comment #56)
> OK, thx for the patch, but please change keyword to taskName or commandName

Fixed

(In reply to comment #58)
> I'm not particularity happy with the wording.

Fixed, I changed it to:
"Are you sure you want to permanently delete all messages and subfolders in the Junk folder?"
with Yes/No buttons.

> And while I'm at it, doesn't usability studies say to use positive sentences
> with checkboxes - easier to grasp "always ask me" vs. "don't ask me".

I looked around in our code and it seems that "don't ask me" is in majority
over "always ask me", so I'm keeping it. Please file a bug on it though -
we should at least be consistent, whichever we choose.
Please include URLs to those usability studies if you have them.

> The patch didn't add a default pref value, BTW.

Fixed
Attachment #252672 - Attachment is obsolete: true
Attachment #252966 - Flags: superreview?(bienvenu)
Attachment #252966 - Flags: review?(bienvenu)
Comment on attachment 252966 [details] [diff] [review]
Patch rev. 3

mail.emptyJunk.confirm"

the name of this pref seems backwards - if it's false, we ask for confirmation; if it's true, we don't. Should it be dontconfirm? Other than that, looks fine to me, thx!
Attachment #252966 - Flags: superreview?(bienvenu)
Attachment #252966 - Flags: superreview+
Attachment #252966 - Flags: review?(bienvenu)
Attachment #252966 - Flags: review+
NB: "Items" works better if you're looking at an RSS feed, which technically doesn't have "messages."  But I don't care what the wording is.
(In reply to comment #59)
> Please include URLs to those usability studies if you have them.

Maybe not a study per say, but I guess the famous Nielsen got his views from somewhere.
<http://www.useit.com/alertbox/20040927.html> 
"7. Use positive and active wording for checkbox labels, so that it's clear what will happen if the user turns on the checkbox. In other words, avoid negations such as "Don't send me more email," which would mean that the user would have to check the box in order for something not to happen."

I'm sure I could dig up more...
I must thank those having a go at fixing this.  Well done lads!
(In reply to comment #60)
> mail.emptyJunk.confirm"
> the name of this pref seems backwards ... Should it be dontconfirm?

Fixed. I chose "dontAskAgain" which is used by some other prefs.

Checked in to trunk at 2007-01-27 13:41 PST.

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Any Chance to get this in for 1.8.1.1 (Thunderbird 2.0)?
Thanks alot for implementing this "feature". 
Product: Core → MailNews Core
here's a screenshot of the menu in action

I know we don't do this for every bug (which perhaps should change) but I like to have something pretty to point to for resolved / verified.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: