Correcting file size units in Firefox

[Zipdox]

Hi Mozillians,

I'm working on a patch
(https://phabricator.services.mozilla.com/D195991) to correct the units
used in Firefox to display file sizes (e.g. for downloads). Currently,
Firefox calculates file sizes in binary units (dividing by 1024), but
uses SI prefixes to display them. Although this might seem like the
"correct" way, it is outdated and is contradictory to IEC 80000-13 and
the SI, and needs to be corrected to prevent confusion. If you are
confused reading this, please consult Wikipedia.
https://en.wikipedia.org/wiki/Byte#Multiple-byte_units

I would like your input regarding this issue. Currently I have these
options and defaults to choose from:

1. Add an about:config option to choose between binary (KiB, MiB, GiB)
and decimal (kB, MB, GB) units and;
A. Default to decimal.
B. Default to binary.
C. Default depending on OS (binary on Windows, else decimal).
2. Change the calculation to decimal and use SI prefixes (kB, MB, GB).
3. Keep binary calculation and change the prefixes to the correct binary
ones (KiB, MiB, GiB).

Please read the comments on the linked patch and let me know your
thoughts. Although this seems like a poll, I'm more interested in
arguments than votes.

Best regards,
Zipdox

[Dave Townsend]

As mentioned in the patch an option for this is overkill and not something we would take. As for what we should do I'm somewhat more interested in what other software does here than rigorously following the standard so I did a quick check of a few other pieces of software as examples:

macOS finder: 1,000 divisor, SI units

Safari: 1,000 divisor, SI units

Windows explorer: 1,024 divisor, SI units

Chrome: 1,024 divisor, SI units.

Edge: 1,024 divisor, SI units.

Lightroom: 1,024 divisor, SI units.

Basically no-one seems to use the binary units and so I don't think they're a good choice, all they can really do is to introduce some confusion to users who notice. As for the divisor, we're currently doing the same thing as most other software I looked at so we probably should carry on doing that. Even though that is arguably wrong from a technical standpoint, the point of standards is to improve interoperability.

--
You received this message because you are subscribed to the Google Groups "firef...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firefox-dev...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/2aaf3f8a-ed07-4cde-8b6c-fd3299bf2676%40zipdox.net.

[Yuri Khan]

On Sun, 17 Dec 2023 at 16:23, Dave Townsend <dtow...@mozilla.com> wrote:

> macOS finder: 1,000 divisor, SI units
> Safari: 1,000 divisor, SI units
> Windows explorer: 1,024 divisor, SI units
> Chrome: 1,024 divisor, SI units.
> Edge: 1,024 divisor, SI units.
> Lightroom: 1,024 divisor, SI units.

I don’t think calling those SI units is accurate. Traditional byte
unit prefixes were K and M — note the capital K for 1024, while SI
uses a small k.

I agree that keeping the tradition of using degrees of 2 and labeling
them with prefixes that sound like SI and look mostly like SI is the
preferred way.

(Just be sure to label bytes with a capital B — small b is for bits.)

[Dave Townsend]

On Sun, 17 Dec 2023 at 10:23, Yuri Khan <yuri....@gmail.com> wrote:

On Sun, 17 Dec 2023 at 16:23, Dave Townsend <dtow...@mozilla.com> wrote:

> macOS finder: 1,000 divisor, SI units
> Safari: 1,000 divisor, SI units
> Windows explorer: 1,024 divisor, SI units
> Chrome: 1,024 divisor, SI units.
> Edge: 1,024 divisor, SI units.
> Lightroom: 1,024 divisor, SI units.

I don’t think calling those SI units is accurate. Traditional byte
unit prefixes were K and M — note the capital K for 1024, while SI
uses a small k.

Yes that's true, these are JEDEC units I guess: https://en.wikipedia.org/wiki/JEDEC_memory_standards#Unit_prefixes_for_semiconductor_storage_capacity

[Zipdox]

On Sun, 17 Dec 2023 at 16:23, Dave Townsend <dtow...@mozilla.com> wrote:

macOS finder: 1,000 divisor, SI units
Safari: 1,000 divisor, SI units
Windows explorer: 1,024 divisor, SI units
Chrome: 1,024 divisor, SI units.
Edge: 1,024 divisor, SI units.
Lightroom: 1,024 divisor, SI units.

Every piece of software you listed is proprietary. Edge is also just MS Chrome.

I just looked around my system to see what some software I use does.

qBittorrent: 1024 divisor, binary prefixes
VLC: 1024 divisor,  binary prefixes
mpv: 1024 divisor,  binary prefixes
Temo: choice between 1000 divisor with decimal prefixes and 1024 divisor with binary prefixes
Thunar: 1024 divisor,  binary prefixes
Nauilus: 1000 divisor, decimal prefixes
GParted: 1024 divisor,  binary prefixes
GNOME Disks: 1000 divisor, decimal prefixes

I think you're overlooking a lot of software and users. Just because some companies are doing it wrong or handing onto ancient traditions, doesn't mean we should do the same.

[Dave Townsend]

On Sun, 17 Dec 2023 at 17:46, Zipdox <zip...@zipdox.net> wrote:

On Sun, 17 Dec 2023 at 16:23, Dave Townsend <dtow...@mozilla.com> wrote:

macOS finder: 1,000 divisor, SI units
Safari: 1,000 divisor, SI units
Windows explorer: 1,024 divisor, SI units
Chrome: 1,024 divisor, SI units.
Edge: 1,024 divisor, SI units.
Lightroom: 1,024 divisor, SI units.

Every piece of software you listed is proprietary. Edge is also just MS Chrome.

Proprietary or not isn't really relevant. What is relevant is that for around 85% of our users Firefox's behaviour matches the operating system's file browser and almost any other browser they might use. Changing makes us less "standard". You could perhaps argue that we should behave differently on macOS and Linux but similar to providing a preference I don't think it is worth the work to do so.

[Marco Bonardo]

My opinion, related to the uppercase VS lowercase k for kB, is that we should stick to the ecosystem. Both Windows and MacOS use K, Ubuntu by default uses k. So at a maximum we could adapt on a per platform basis (where we'd assume Linux prefers lowercase k, even if I suspect it's a per file-manager thing, needs verification). That'd also be trivial to do with Fluent.

Related to the decimal vs binary, none of the above OS are using binary, again imo the ecosystem wins, as otherwise we'd just add cognitive weight on the user.

Related to the divisor, I'd _personally_ prefer to be technically correct. But then I fear the user seeing one size/speed in Firefox, and a different one in another browser, will be confused, or even file a bug.

We could again stick to the OS file manager for consistency reasons. Though then we'll be internally inconsistent in Firefox, and that would increase QA costs, cause file size numbers will differ across OS, as this is not just an uppercase/lowercase thing.

Additionally on Linux file managers are not consistent, as reported above, so the "stick to the OS" rule would be unapplicable. It would not be better than today.

Is the benefit worth the added complexity cost? At the moment, I'd say no.

Cheers,

Marco

[Yuri Khan]

On Mon, 18 Dec 2023 at 00:45, Zipdox <zip...@zipdox.net> wrote:

> Thunar: 1024 divisor, binary prefixes

Thunar has a user setting, Edit → Preferences → Display → [x] Show
file size in binary format. If checked, it shows 3.5 KiB, if
unchecked, 3.6 kB (on en_US.UTF-8 locale).

[Zipdox]

If we don't make it configurable, there will always be a users with
conflicting file size units. I insist on making in configurable. What
kind of tests do I need to do to make this acceptable?

[Gijs Kruitbosch]

Marco, Dave and I discussed this topic today.

While we appreciate you taking the time to contribute to Firefox we believe changing from kB/KB to KiB (or changing the divisor) is a bad idea - and a pref would make it worse. No amount of tests will make doing this acceptable and we will not accept a patch that does this.

As with any patch, this is a cost/benefit trade-off. In terms of the implementation cost of a pref for this, we would:

1. need to add the pref

2. need to duplicate many of these strings (not a precise search due to the limitations of regular expressions, but a bunch more than "just" the downloads panel. It’s also worth noting that as discussed in the bug, there are more subtle arguments to be had about whether all of these pieces of UI should use the same unit or not, so we could end up with multiple prefs and different units, adding yet more complexity)

3. duplicate all the implementations referencing those strings

4. write tests for all of that

5. make all our volunteer localizers localise all those duplicated strings (and hope they don't get any mixed up)

6. make QA verify and document the possible configurations and update all downloads-related testcases

7. have to maintain all of that forever

In terms of benefits, all browsers other than Safari, and all OSes, show JEDEC units. That's the ecosystem that Firefox is a part of. If we changed the default behaviour this would likely confuse users because we would no longer be aligned with that ecosystem.

If we kept the new behaviour behind a pref, most people would not notice anything and probably still file bugs about this once every few years because they wouldn't know the setting exists or complain about its defaults. Settings are a good option for things that have significant impact on the user’s experience and are in broad demand, not for small tweaks like this.

The one thing that we could consider is changing the fluent references to use `kB` instead of `KB` on platforms that didn’t opt for JEDEC (e.g. Linux), for strings where this is appropriate. Doing so would require defining a new term for KB with a `PLATFORM()` selector, updating the downloads strings to use the new term, and make sure that any contexts that use those strings also load the ftl file that defines the new term. Then we’d need to progressively update other uses of KB/kB to use the new term as well. That’s still very much a non-trivial change, though we would take a contributed patch.

Marco (module owner of the Downloads code)

Dave & Gijs (module co-owners of Firefox Desktop)

[Zipdox]

On 12/20/23 15:20, Gijs Kruitbosch wrote:

> Marco, Dave and I discussed this topic today.
>
>
> While we appreciate you taking the time to contribute to Firefox we
> believe changing from kB/KB to KiB (or changing the divisor) is a bad
> idea - and a pref would make it worse. No amount of tests will make
> doing this acceptable and we will not accept a patch that does this.
>
>
> As with any patch, this is a cost/benefit trade-off. In terms of the
> implementation cost of a pref for this, we would:
>
>

> 1.

>
>    need to add the pref
>

> 2.

>
>    need to duplicate many of these strings

> <https://searchfox.org/mozilla-central/search?q=%5Cb%5Bkmgt%5Db%5Cb%28%5B%5E%5C%2F%5D%7C%24%29&path=.%7Bproperties%2Cftl%7D&case=false&regexp=true>(not

>    a precise search due to the limitations of regular expressions, but
>    a bunch more than "just" the downloads panel. It’s also worth noting
>    that as discussed in the bug

>    <https://bugzilla.mozilla.org/show_bug.cgi?id=106618>, there are

>    more subtle arguments to be had about whether all of these pieces of
>    UI should use the same unit or not, so we could end up with multiple
>    prefs and different units, adding yet more complexity)
>

> 3.

>
>    duplicate all the implementations referencing those strings
>

> 4.

>
>    write tests for all of that
>

> 5.

>
>    make all our volunteer localizers localise all those duplicated
>    strings (and hope they don't get any mixed up)
>

> 6.

>
>    make QA verify and document the possible configurations and update
>    all downloads-related testcases
>

> 7.

>
>    have to maintain all of that forever
>
>
> In terms of benefits, all browsers other than Safari, and all OSes,
> show JEDEC units. That's the ecosystem that Firefox is a part of. If
> we changed the default behaviour this would likely confuse users
> because we would no longer be aligned with that ecosystem.
>
>
> If we kept the new behaviour behind a pref, most people would not
> notice anything and probably still file bugs about this once every few
> years because they wouldn't know the setting exists or complain about
> its defaults. Settings are a good option for things that have
> significant impact on the user’s experience and are in broad demand,
> not for small tweaks like this.
>
>
> The one thing that we could consider is changing the fluent references
> to use `kB` instead of `KB` on platforms that didn’t opt for JEDEC
> (e.g. Linux), for strings where this is appropriate. Doing so would
> require defining a new term

> <https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#terms>for

> KB with a `PLATFORM()` selector, updating the downloads strings to use
> the new term, and make sure that any contexts that use those strings
> also load the ftl file that defines the new term. Then we’d need to
> progressively update other uses of KB/kB to use the new term as well.
> That’s still very much a non-trivial change, though we would take a
> contributed patch.
>
>
> Marco (module owner of the Downloads code)
>
> Dave & Gijs (module co-owners of Firefox Desktop)
>
> On 19/12/2023 15:57, Zipdox wrote:
>> If we don't make it configurable, there will always be a users with
>> conflicting file size units. I insist on making in configurable. What
>> kind of tests do I need to do to make this acceptable?
>>

If it's too much work, I think it might be acceptable to leave all
memory related unit calculations to use a 1024 divisor, and just change
the units to binary prefixes. Looking at memory is not something users
do all the time. I've already added a pref in my patch to change the
units, and it already works. I just need to look at the localization for
that.

[Dave Townsend]

As Gijs already said, the rest of the ecosystem we're in uses JEDEC units so a patch to switch us to binary units would not be accepted.

--
You received this message because you are subscribed to the Google Groups "firef...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firefox-dev...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/a3ba7cd2-be57-4d88-ac8d-3c54ed512d58%40zipdox.net.