Closed Bug 368043 Opened 18 years ago Closed 18 years ago

Infinity% displays on status bar

Categories

(Thunderbird :: Mail Window Front End, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wgianopoulos, Assigned: BenB)

References

Details

(Keywords: fixed1.8.1.2, regression)

Attachments

(1 file, 1 obsolete file)

I just upgraded from 2.0 beta1 to 2.0 beta2.  Thunderbird now displays a very odd looking button with the label "Infinity%" in the statusbar.  Clicking on the button brings up a window with folder quota information.  I suspect what is going on here is that because there is no quota specified, it ends up being 0.  The window says "xxxxxKB out of 0KB used" and it therefore calculates a percentage used of infinity.

This button should not be displayed at all if the folder has no quota specified.
Flags: blocking-thunderbird2?
Blocks: 251537
Keywords: regression
Summary: Infinity% diaplyes on status bar → Infinity% displays on status bar
Blocks: 278096
No longer blocks: 251537
> This button should not be displayed at all if the folder has no quota
> specified.

That's exactly what I'm trying, and I don't see it with my server (no quota).

Maybe that's a server bug? Which exact server and server version do you use?

Ben
Assignee: mscott → ben.bucksch
Funny.  I was sending that but it mid-air collided with your comment.

This is a Lotus Notes Domino mail server using their IMAP server.
The server supports quotas, but there is no quota on my Inbox.

This seems to result in max being 0 so used/max yields infinity.

I suggest infunction UpdateStatusQuota replacing:

  if (valid.value)

with:

  if (valid.value && max.value != 0)
Or perhaps this should be being handled in the backend code and valid.value should be false if max.value is zero.
> this should be being handled in the backend code

Indeed.

What do you see in the Folder Properties dialog? (Click on the statusbar display, or via Edit menu)
From reading RFC 2087 it does not appear the server is supposed to be returning
any quota information if there is no quota on the folder, so I guess this is a
server bug.  It seems that it is useful to have it work as this server does,
however, as it does permit me to see the disk space being used in the folder
properties in the quota tab.  But I see nothing in the RFC indicating that
there is any special value in the MAX filed that indicates unlimited. I t does
say "Resources not named in the list are not limited in the quota root. Thus,
an empty list means there are no administrative resource limits in the quota
root." implying that it should not be returning quota information at all in
this case.

However, as many corporate users are forced to receive their e-mail on brain
damaged Notes servers and this looks particularly ugly and seems easy to work
around perhaps this simple fix is warranted.  It is probably always a good idea
to guard against dividing by zero anyway.

I thought I had already said the Folder properties indicate the actual used bytes and 0 bytes for maximum. Quota root ="".  It must have special case code for max being 0 as it is showing 0% used rather than Infinity.  So maybe that is what should be done for consistancy.
> [RFC] does say "Resources not named in the list are [unlimited]" implying
> that it should not be returning quota information at all in this case.

No, that's the opposite conclusion. it says |no quota listed -> unlimited|, but you said |unlimited -> no quota listed| is unspecified.

> it does permit me to see the disk space being used [even if not quota]

Yes, I guess that's a good reason for the behaviour.

> always a good idea to guard against dividing by zero anyway.

True :). Glad this is JS, otherwise it would probably be a crash.

So, bienvenu, can you confirm that you intentionally defined the max in the IDL sattribute to be 0 to express unlimited?

If so, we should fix the IDL (make that explicit in the comment in IDL), and
fix the statusbar display to not show up at all in this case (progressbar makes no sense).
I'm not sure I'm following this correctly - I believe we're passing the data given to us by the server through the idl, right? I.e., from this line of code:

PR_sscanf(parengroup, "(STORAGE %lu %lu)", &used, &max) == 2) )

There's nothing intentional or explicit about making 0 be unlimited, at least at the idl level. We're just passing it around. It's been years since this code was written, so I could be forgetting something. But your proposed changes sound fine to me.
OK, per IRC:
On branch: Hack frontend to deal with max = 0. Probably only the statusbar, just don't show up, don't care about Folder Properties (no regression there).

On trunk:
* Change IDL to make this case explicit (options below)
* change backend to special-case this max = 0 and use the new API
* adapt quota statusbar display code to not show up in that case
* adapt Folder Properties code to making it explicit
IDL, alternatives:
1: Add an "out boolean aUnlimited", show "unlimited" or "no quota" in Folder Properties, but still show usage
2: Add an "out boolean aMaxInvalid", show neither max nor unlimited in Folder Properities, but still show usage
3: Define in comment that maxKB = -2 is a magical value for "max invalid". Same UI as (2).

Given that David Bienvenu didn't want (1), I'll probably go with (3).
why is maxKB = -2 as a magical value better than maxKB = 0 as a magical value? Especially since 0 is really invalid, whereas 0xfffffffe is possibly not invalid?
A simple one-liner to fix the bug on the branch.

I tested it with my server with quota, but of course can't test with the buggy Lotus Notes server.

Bill, if you have the capability to apply the patch, or to supply login credentials to a Notes test server, that would be good. But the fix is so stupid, it must work :).
Attachment #252810 - Flags: review?(bienvenu)
Comment on attachment 252810 [details] [diff] [review]
Fix, branch, v1 (no IDL comment change)

how about max.value != 0 ?
> why is maxKB = -2 as a magical value better than maxKB = 0 as a magical value?

I could imagine a server to say that it doesn't allow anything in that folder, i.e. usage = max = 0. That's of theoretical nature, but so is usage > max = 0 :).

I don't care either way. Just be explicit in the IDL [comment].

> how about max.value != 0

Because "-19896 KB" used makes no sense, which you'd get with max < 0.
(and because we said earlier that -1 *may* happen, and we might spec -2 as magical value)
eh, "-50% used". anyways.

I think we are - *I* am - making this overcomplicated. This bug is trivial. Let's just get it in.
Attachment #252810 - Flags: review?(bienvenu) → review+
yes, I truly think just a comment in the idl, plus the js change you've already made, are all we need.
Attached patch Fix, v2Splinter Review
Same patch, with IDL comment change.

Do you want this one on branch as well?
Attachment #252816 - Flags: review?(bienvenu)
Comment on attachment 252816 [details] [diff] [review]
Fix, v2

sure, thx!
Attachment #252816 - Flags: review?(bienvenu) → review+
Attachment #252816 - Flags: superreview?(mscott)
Attachment #252816 - Flags: approval-thunderbird2?
Attachment #252810 - Attachment description: Fix, branch, v1 → Fix, branch, v1 (no IDL comment change)
Attachment #252810 - Attachment is obsolete: true
Attachment #252816 - Attachment description: Fix, trunk, v2 → Fix, v2
Attachment #252816 - Flags: superreview?(mscott)
Attachment #252816 - Flags: superreview+
Attachment #252816 - Flags: approval-thunderbird2?
Attachment #252816 - Flags: approval-thunderbird2+
Thanks for the quick reviews.

Checked Fix v2 into trunk and 2.0 branch. FIXED.

Bug 368332 filed about Folder Properties dialog.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking-thunderbird2?
Keywords: fixed1.8.1.2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: