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)
SeaMonkey
MailNews: Address Book & Contacts
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).
Comment 1•24 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.
I'm also not clear on why this is different than the current UI pref.
Assignee | ||
Comment 3•24 years ago
|
||
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.
Assignee | ||
Comment 5•24 years ago
|
||
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 7•24 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 9•24 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
Assignee | ||
Comment 10•23 years ago
|
||
better to rot on my list (or racham's) than rot on chuang's list.
Assignee: chuang → sspitzer
Comment 11•22 years ago
|
||
removed tiantian from cc (bad alias; sends mail to jhooker)
Assignee | ||
Comment 12•22 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•