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)

x86
Windows NT
defect

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.
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.
Keywords: intl
reassign to ftang
Assignee: matt → ftang
Low priority item, Mark it as P5 Future. Move it over to nhotta.
Assignee: ftang → nhotta
Priority: P3 → P5
Target Milestone: --- → Future
Reassign to jbetak.
Assignee: nhotta → jbetak
Status: NEW → ASSIGNED
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
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
nhotta, could you please review? It's a simple little change...
r=nhotta
alecf, I have to pester you with yet another review request - this one should be pretty painless tough...
painless or tough? :) sr=alecf
tough luck. Freudian misspelling or not - away it goes ;-) Thanks everyone!
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
QA Contact: sairuh → teruko
Verified as fixed in 2001-05-24 build.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: