Closed Bug 148026 Opened 22 years ago Closed 22 years ago

We should not return error when default locale is used for unix platform charset

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: shanjian, Assigned: shanjian)

References

Details

(Keywords: intl)

Attachments

(1 file)

Carried over from bugscape 15945.

In /nsUNIXCharset.cpp, if charset could not be achieved from nls_infl and locale
name, we will default to iso-8859-1. The default value is fine, but in such case
we should return a success code. Otherwise caller might be confused.
Attached patch patchSplinter Review
Comment on attachment 85539 [details] [diff] [review]
patch

r=bryner
sr=darin, 
(from bugscape 15945)
Attachment #85539 - Flags: superreview+
Attachment #85539 - Flags: review+
fix checked into trunk. 
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Code issue? QA -> yokoyama for now. please reassign if needed.
Keywords: intl
QA Contact: ruixu → yokoyama
Blocks: 141008
Keywords: nsbeta1+
Summary: We should return error when default locale is used for unix platform charset → We should not return error when default locale is used for unix platform charset
does this stop the crashing ?
I do not know because I could not reproduce the problem here. But the problem
targeted here is a problem and it caused many other problem as well. We should
fix it no matter what, and that's why I check it to trunk. For branch, since the
crash no longer exist after RC1, we probably don't want to do anything about it
right now. 
>For branch, since the crash no longer exist after RC1, we probably don't want 
>to do anything about it right now. 
? I thought the crash is AFTER RC1 and IN N7PR1 (between RC2 and RC3). 
Should we land this for branch?
The problem happens in PR1, and we are not going to respin PR1. In current
branch (and next release), we don't have this problem any more. Do you think you
can get approval for this?
>The problem happens in PR1, and we are not going to respin PR1. 
>In current branch (and next release), we don't have this problem any more.
Why is the branch differ from the PR1? What make the difference? Is that because
they land the nsLocalFile patch?
Most likely, but I am not absolutely sure. Bryner put more information in
bugscape 15945.
Keywords: adt1.0.1
blaker? why you add adt1.0.1 here? we don't think we need this anymore. 
Marking as adt1.0.1-, because this does not appear to be a problem on the
branch.  pls renominate, should someone feel that issue is on the branch and
needs to be resolved before 1.0.1 ships. thanks!
Keywords: adt1.0.1adt1.0.1-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: