No hidden pref or UI for limiting # of cards in Collected Abook to aid performance

RESOLVED INVALID

Status

P3
major
RESOLVED INVALID
18 years ago
14 years ago

People

(Reporter: esther, Assigned: sspitzer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Using trunk builds 11/13/2000 on win98, mac and linux we don't have the hidden
pref to limit the # of cards allowed in the collected abook (still TBD) to avoid
performance problems.  Seth looked in the UI for an alert that would warn the
users if this number was hit, but couldn't find one.

Note: We don't think this is not the same as the Preference item we give the
user to limit the number of cards they collect for reasons other than
performance (i.e. they don't want a lot of cards showing up in autocomplete).
(Reporter)

Updated

18 years ago
QA Contact: esther → stephend

Comment 1

18 years ago
I don't understand how this is different than the pref we currently have in the
prefs UI. I don't think we'd want to put up a warning every time they reached
their limit.

Comment 2

18 years ago
I'm also not clear on why this is different than the current UI pref.
ok, we current have a pref that the user can set to limit the # of cards in the
CAB. ("mail.collect_email_address_size_limit")

the user can jack that up to 10,000.  Then when compose slows down to a crawl
(because of autocomplete, they have no idea.)

I propose this:

I think we also need two new hidden prefs

"mail.collect_warn_limit" default to n (where n is a number we determine on the
target machine and n is greater than the default value for
"mail.collect_email_address_size_limit")

"mail.collect_warned_user" defaulted to false

the first time (we know because "mail.collect_warned_user" == false) the user
jacks up the "mail.collect_email_address_size_limit" pref greater than the
"mail.collect_warn_limit" pref, we put up an alert that says:

"Warning, setting this pref to a large value can slow down compose performance
because..."

and then we set "mail.collect_warned_user" to true, and never warn them again.

there would not be any pref UI for these two new hidden prefs, but we would have
UI for the alert.

Comment 4

18 years ago
What about we just don't let the user set the CAB to a number higher than X? 
(where X is a reasonable value we determine).  When they try and enter a number 
>X, we show a dialog, "The maximum number of entries the Collected Address Book 
can hold is X." User clicks OK and we enter X into the field. 

Users expect the system will make the correct decisions for them. When they get 
warning/info dialogs that they don't understand, they just click OK and "make it 
go away" out of habit. 

If desirable, we could have a hidden pref that would let advanced users raise 
this limit.
jglick:  I like your solution much better.

have a hidden pref for the max (that power users can change)
and if they try to set the other pref > than the max, we alert.

can you add that to the spec?

Comment 6

18 years ago
will do.

Comment 7

18 years ago
another thing we could is put some description next to the pref explaining why
someone might want to change it and what the side effects of changing it are.

Comment 8

18 years ago
reassigning to chuang.
Assignee: putterman → chuang

Comment 9

18 years ago
Instead of preventing the user from increasing the limit, what about warning
them about the consequence when they do it?  Something like if newval > X then
warn "some msg".
QA Contact: stephend → fenella

Updated

17 years ago
QA Contact: fenella → nbaca
better to rot on my list (or racham's) than rot on chuang's list.
Assignee: chuang → sspitzer

Comment 11

17 years ago
removed tiantian from cc (bad alias; sends mail to jhooker)
the CAB doesn't work like this anymore.

http://www.mozilla.org/mailnews/arch/cab.html
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.