Closed Bug 60111 Opened 24 years ago Closed 22 years ago

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

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P3)

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: esther, Assigned: sspitzer)

Details

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).
QA Contact: esther → stephend
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.
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.
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?
will do.
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.
reassigning to chuang.
Assignee: putterman → chuang
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
QA Contact: fenella → nbaca
better to rot on my list (or racham's) than rot on chuang's list.
Assignee: chuang → sspitzer
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
Closed: 22 years ago
Resolution: --- → INVALID
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.