Closed
Bug 64754
Opened 24 years ago
Closed 14 years ago
Properties of Folders should also show Space Used (size)
Categories
(SeaMonkey :: MailNews: Message Display, enhancement)
SeaMonkey
MailNews: Message Display
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: Peter, Unassigned)
References
Details
(Keywords: helpwanted)
Right-Click on Properties of Folders should also show Space Used.
This was a feature in NC4.x and was very useful in determining how much space
was being used (wasted?) by a particular folder. It is a useful tool in cleaning
up folder directories.
Reporter | ||
Updated•24 years ago
|
David Bienvenu is working on both offline features as well as disk space
management. I'm pretty sure he's got a tracker bug for this, I'll find it.
We have bug 17217, which is for News disk space management. Not sure if that
will apply to other folders as well.
Comment 3•24 years ago
|
||
yes, this can apply to imap and local folders, to account for the .msf file
size, and local mail store (offline msg store for imap and news too).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually, I meant if we should be lumping them into the same bug (bug 17217),
since you marked this NEW and it applies to folders, does it belong to you or
Seth?
Comment 5•24 years ago
|
||
it belongs to whoever's going to do folder properties UI. I don't know who that
is. But, no, it doesn't belong in bug 17217. I meant to say that it does apply
to other folders.
I think Karen Huang might own this, not sure though. Thanks for the
clarification, David.
Updated•24 years ago
|
Keywords: mozilla0.9
Updated•24 years ago
|
Keywords: mozilla0.8.1
Updated•24 years ago
|
Keywords: mozilla0.8
Updated•24 years ago
|
Keywords: mozilla0.8.1
according to updated specs at http://www.mozilla.org/mailnews/specs/folder/
"Space used:" should indeed be displaying
CC jg@cyberstorm.demon.co.uk who may be working on this somewhere already.
Updated•21 years ago
|
Severity: normal → enhancement
Updated•21 years ago
|
Summary: Right-Click on Properties of Folders should also show Space Used → Properties of Folders should also show Space Used
Comment 10•21 years ago
|
||
*** Bug 182887 has been marked as a duplicate of this bug. ***
Comment 11•21 years ago
|
||
Upgrading from Enhancement to Normal, since this feature is part of the
specification.
See bug 219797, which suggests an alternate layout for the properties window.
One quite good suggestion there is to put a Compact Folder Now button in the
window. This would be an enormous improvement over having "Compact This Folder"
in the context menu.
Severity: enhancement → normal
Updated•21 years ago
|
OS: Windows NT → All
Hardware: PC → All
Summary: Properties of Folders should also show Space Used → Properties of Folders should also show Space Used (size)
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•20 years ago
|
Assignee: sspitzer → mail
Updated•16 years ago
|
Assignee: mail → nobody
QA Contact: huang → message-display
Comment 12•15 years ago
|
||
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
Status: NEW → UNCONFIRMED
Comment 13•15 years ago
|
||
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 14•15 years ago
|
||
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 15•15 years ago
|
||
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 16•15 years ago
|
||
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
Reporter | ||
Comment 17•15 years ago
|
||
This bug still applies to Seamonkey (and to Thunderbird). Please re-confirm it (and change to "MailNews Core").
Comment 18•15 years ago
|
||
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
Reporter | ||
Comment 19•15 years ago
|
||
This bug still applies to Seamonkey (and to Thunderbird). Please re-CONFIRM it
(and change to "MailNews Core").
Comment 20•14 years ago
|
||
In reply to comment #19 (better late than never :-/ )
> This bug still applies to Seamonkey (and to Thunderbird). Please re-CONFIRM it
> (and change to "MailNews Core").
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101209 Firefox/4.0b8pre SeaMonkey/2.1b2pre - Build ID: 20101209025017
This bug still applies indeed, but I'm downgrading it to RFE and adding some CC who have (I think) the power to declare it WONTFIX.
About moving to MailNews Core: IIUC this is a UI bug, and UI is forked between Thunderbird and SeaMonkey, so if the Thunderbird guys want it too they'll need another bug (Neil, Karsten, if I'm mistaken please move the bug where it belongs; Wayne, if you think Thunderbird needs this, please file a bug for it).
The following may or may not be reason enough for WONTFIX:
On POP and Local Folders (but not on NNTP and I don't know about IMAP) the thread-pane line for each message includes in the "Order received" column (if you have it displayed) how many bytes the folder uses up to, but not including, that message (so adding one short message will show you the approximate size of the folder as the "Order received" of the new message). Deleting one or more messages won't reclaim the corresponding bytes, a Compacting operation (which can be triggered manually at any time, or automatically if there is enough "deleted space" for it to reclaim) is necessary for that after the delete.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 21•14 years ago
|
||
Can't you see the size of all folders by using the columnpicker?
(Also available are the total and number of unread messages.)
Comment 22•14 years ago
|
||
(In reply to comment #21)
> Can't you see the size of all folders by using the columnpicker?
> (Also available are the total and number of unread messages.)
Ah, right: the column picker in the left pane. This is probably WONTFIX then? (though redundancy is not necessarily bad: see ux-discovery vs. ux-minimalism keywords as the two sides of the argument).
Comment 23•14 years ago
|
||
WONTFIX since there is a folder column to show the folder sizes. Better to file a new bug about UX discovery if you (or Peter) wants.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•