601939 - filter message size is imprecise with regard to usage of KB (rounds to KB, can't express bytes exactly)

Status: NEW

(MailNews Core :: Filters, enhancement)

Description

[plop]

User-Agent:       Mozilla/5.0 (X11; DHP; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100912 Gentoo Firefox/3.6.9
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; fy-NL; rv:1.8.1.23) Gecko/20100130 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0

tools > Message filters > new > Size

When using GB local, the label in the choose list is "Size (kB)". Since at most 2009 (and maybe 2008), "kB" means 10^3 Bytes. A new set of units have been introduced for computing world: the "*i*nformation *B*ytes and *b*its".

As TB3 has come out after this new ruleset, kB literaly means une thouthand bytes. What i expect to be wrong. As advanced user, i bet the dev guy meant 2^10 bytes, what should now be written "kiB".

Any way, yesterday, i wanted to create a filter that would match 24B long messages; whatever 1kB means 1000 or 1024, what should i type in the right text field to make the rule match 24B ? 0.024 ? 0.0234375 ?

Third issue: when using the french version of TB ( a friend made a screen shot for me on a french MacOS), it's just written "Taille"; then, good luck to guess the expected unit.

4th issue (not a filter one, but still related): when i activate the size column, the same issue happens again: it's written kB. Does 36kB mean 36000B ? between 35501 and 36500 ? between 36352 and 37376 ? between 36000 and 36999 ? between 36864 and 37887 ? 

=> the right click menu should offer a "message properties" entry, containing, amongst other ideas:
- importants parts of the header
- physical location of locale cache
- remote location for Imap messages if imap
- exact size to the byte, aproximation in Human unit (kiB, MiB)
- order received ... 

I fill all this in the same bug, because it's closely related to locales, and langage ... 

Of course, similar issues should be tracked in all other langages :)

Reproducible: Always

Comment 1

[Joshua Cranmer [:jcranmer]]

(In reply to comment #0)
> When using GB local, the label in the choose list is "Size (kB)". Since at most
> 2009 (and maybe 2008), "kB" means 10^3 Bytes. A new set of units have been
> introduced for computing world: the "*i*nformation *B*ytes and *b*its".

The answer is indeed 1024 bytes. The display terminology is likely consistent with the display value for Size, which is also in KB.

However, the practical implication is rather unimportant, since...

> Any way, yesterday, i wanted to create a filter that would match 24B long
> messages; whatever 1kB means 1000 or 1024, what should i type in the right text
> field to make the rule match 24B ? 0.024 ? 0.0234375 ?

You can't do this with the size term. Size only matches integral values of KB, with messages less than 1KB being treated as 1 KB.

> Third issue: when using the french version of TB ( a friend made a screen shot
> for me on a french MacOS), it's just written "Taille"; then, good luck to guess
> the expected unit.

That is a problem with the French localization team; it is to whom you should address that bug.

> 4th issue (not a filter one, but still related): when i activate the size
> column, the same issue happens again: it's written kB. Does 36kB mean 36000B ?
> between 35501 and 36500 ? between 36352 and 37376 ? between 36000 and 36999 ?
> between 36864 and 37887 ? 

The best way to describe it is any value between N * 1024 and (N + 1) * 1024 - 1, inclusive. Obviously, that is far more detail than can be described in a simple entry.

It is also important to note that the primary intent of the filter criterion is to look for "very large" messages, as evidenced by bug 19402. So, the difference between 10000 bytes and 10240 bytes is rather unimportant in the grand scheme of things.

> => the right click menu should offer a "message properties" entry, containing,
> amongst other ideas:
> - importants parts of the header

This is effectively the message display.

> - physical location of locale cache

Not sure what you mean here.

> - remote location for Imap messages if imap

The account column provides this.

> - exact size to the byte, aproximation in Human unit (kiB, MiB)

The size column doesn't give the exact size, but it's close enough for most uses.

> - order received ... 

That is yet another selectable column.

Comment 2

[plop]

> You can't do this with the size term. Size only matches integral values of KB,
with messages less than 1KB being treated as 1 KB.

What means, for the filter, all messages with a size below 1024B all have the same size ? so, to make it short, for this filter, 42=69 ?

> That is a problem with the French localization team; it is to whom you should
address that bug.

I am asking you to rectify kB into kiB, and check this mistake in all languages; i am not going to check all languages one by one, an create "probably" 50 reports, one per langage ... the mistake is not the same in english and french, but the target, what should be stated *IS* the same in both langages !

> The best way to describe it is any value between N * 1024 and (N + 1) * 1024 -
1, inclusive. Obviously, that is far more detail than can be described in a
simple entry.

or ... simply use bytes instead of kilos ! precise ! undivisible !

> It is also important to note that the primary intent of the filter criterion is
to look for "very large" messages, as evidenced by bug 19402. So, the
difference between 10000 bytes and 10240 bytes is rather unimportant in the
grand scheme of things.

I wanted to select 24B messages, and reject 23B and 25B messages. The english wording << is >> ... *IS* precise. 1kiB=1024B.

If the filter meant to use aproximation, this should be stated: "is about", "is aprox", "is around" ... the menu/list is large enough to accept a second workd.

And of course, this imprecision should also be recitified in all langages.

>> - physical location of locale cache

in which file the message is stored. At the moment, it's the location of folder; but when the three 2GiB bugs will be fixed (in a few years ?), folders may be spread over several files.

>> - remote location for Imap messages if imap
> The account column provides this.

Having to fly around to grab infos is exhausting. Thunderbird tends to present things a convicial, and intuitive way. The intuitive habit, for most modern GUI is to provide as much as possible, for every single object, a specific right click menu, where the last entry is "properties". Il all OS that are at most 15y old I know; in all GUI that have been developped by serious people (I won't speak about the many quick student projects). 

>> - order received ... 
> That is yet another selectable column.

and it should be reminded in a properties pop-up.

The new TB3 layout tends to look more and more like a filer; TB3 is, as of today, the only filer i know, that does not have a property entry in the right click menu. Even Firefox have it in some contextes !!! TB3 is lacking context specific "object properties pop-up".

But if you want me to be strict, i can spread this bug over more than 100 new bugs; one per langage for filter, one per langage for columns, one for asking new pop-up ... or we can stick to this single bug for most of it.

Comment 3

[:aceman]

It seems most of your requests were answered. If not, please file a new bug for each of your request, not all into one.
The KiB vs. KB display is bug 108147.
So what is left is the possibility to specify a filter to match exact number of bytes, not round to kilobytes. That is not currently possible, but I confirm the request as valid.

Comment 4

[plop]

... or the interface could at least specify explicitely that the size is rounded, and say if it's rounded up or down. This fix does not need to write any code: just update internal documentation, pop-ups, help pages, or contextual description.

Or stop using kib, and use bytes. 

Documentation does not allow to determine if a 1025b message will match 1k, 2k, or none of those values.

Comment 5

[Wayne Mery (:wsmwk)]

comment 4 seems rather impractical.  
bug 637914 may be a useful reference

Comment 6

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.