Closed
Bug 41891
Opened 24 years ago
Closed 24 years ago
Accept-Language list cannot be at a zero count
Categories
(SeaMonkey :: Preferences, defect, P5)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: momoi, Assigned: jbetak)
Details
(Keywords: intl)
Attachments
(1 file)
** Observed with 6/7/2000 Win32 **
Two problems: (probably related)
1. Currently if we have a single Accept-Language entry
in the Accept Language list, we cannot delete it.
No matter how much you try, it stays on.
2. When that single language is not English EN, which
is probably the default, then if you attempt to delete it,
it does not get deleted. But when you click on OK button
anyway after the deletion attempt, the next time you open this
pref window, the last entry had been deleted and then replaced
by the default EN, which I did not intentionally choose.
Both of these are incorrect.
A. On a new profile, Accept-language list should be
populated with the default for that locale.
B. But once the user deletes the default entry, the
list should be empty. That is after all what the user
wants. No preference for languages.
We should not offer the locale default if the user
delete all entries. In such a case, we should send nothing
for Accept Language.
Additional Data:
Maybe there is a disconnection between the UI here and the
prefs.js entry. I am observing that no values have been
changed from the original 3 item entry in the pref,
user_pref("intl.accept_languages", "ja, fr, en");
I only see "en" left in the Pref Dialog window.
I think we have more than a few problems with Accept-Language
pref stuff.
Reporter | ||
Comment 1•24 years ago
|
||
I was wrong about the "Additional Data" section.
I looked at a wrong prefs.js -- I have so many on my hard disk.
Pref values are indeed getting deleted and empty when
the last item is deleted but TH UI dialog still says EN.
This last part could be related to a bug assigned to
mcafee@netscape.com.
Comment 3•24 years ago
|
||
Low priority item, Mark it as P5 Future. Move it over to nhotta.
Assignee: ftang → nhotta
Priority: P3 → P5
Target Milestone: --- → Future
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•24 years ago
|
||
moving to 0.9.1, Since 57720 requires a larger code refactoring than expected,
I'll accommodate for expediency's sake the fix there.
Depends on: 57720
Target Milestone: Future → mozilla0.9.1
Assignee | ||
Comment 6•24 years ago
|
||
Assignee | ||
Comment 7•24 years ago
|
||
removing dependecy on bug 57720. Since the code refactoring there is pretty big
I'm divorcing these two issues to increase likelihood of a quick review and
check-in.
No longer depends on: 57720
Assignee | ||
Comment 8•24 years ago
|
||
nhotta,
could you please review? It's a simple little change...
Comment 9•24 years ago
|
||
r=nhotta
Assignee | ||
Comment 10•24 years ago
|
||
alecf,
I have to pester you with yet another review request - this one should be
pretty painless tough...
Comment 11•24 years ago
|
||
painless or tough? :)
sr=alecf
Assignee | ||
Comment 12•24 years ago
|
||
tough luck. Freudian misspelling or not - away it goes ;-)
Thanks everyone!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
QA Contact: sairuh → teruko
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•