Closed Bug 58604 Opened 25 years ago Closed 23 years ago

License agreement dialog does not contain anything when locale is ja_JP.

Categories

(SeaMonkey :: Installer, defect, P3)

Product:
SeaMonkey
Component:
Installer
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: teruko, Assigned: samir_bugzilla)

Details

(Whiteboard: [rtm++])

Attachments

(1 file)

Patch for fix to display the license.
1.24 KB, patch
Details | Diff | Splinter Review
If you use ja_JP locale on Redhad Linux system, the license agreement dialog does not contain anything. Steps of reproduce 1. Start ./netscape-installer 2. Click on Next button on Readme dialog Next dialog does not contain anything. I tried English, German, Russian locales. In every locale, the dialog contains the license agreement correctly. Tested 2000-10-30 MN6 Linux build.
Nominating this for RTM.
Keywords: rtm
Any advice on why ja_JP would be special here?
Teruko, Does the README show up in the welcome dialog (the first dialog)?
Tao, I mean to address my 2000-10-31 10:41 comment to you specifically.
The README screen shows up , but not the second one. LC_ALL makes difference. If LC_ALL is set to ja_JP.EUC, we'll get this problem.
This seems odd because the REDAME and License loading mechanism and widgets used to display both are identical. The only divergence can be that one is localized and the other is not. Even given this cited divergence a difference wouldn't be expected in whether they display. Will pay Teruko a visit to examine the installer build configuration files.
QA Contact: gemal → gbush
Changed QA contact to myself.
QA Contact: gbush → teruko
This sounds more like a problem in the Japanese package than an installer problem for Samir to fix, but awaiting results of investigation
Whiteboard: [rtm need info]
Actually, after investigation this is a problem with the Linux installer core code. I have a fix thanks to dbragg's brainstorming help. Basically, I read the README into memory in one fell swoop and then give the buffer to GTK. GTK in turn makes its own internal copy. So now I must release the memory. I misunderstood the semantics and did not release the unless we experienced an error condition and bailed out. The patch is simple need to free the buffers that we allocate for the readme and then for the license.
Status: NEW → ASSIGNED
Target Milestone: --- → M19
Don/Dan, Please review/super review this patch. Thanks.
Seeing as how I was there hovering over your shoulder when you came up with the fix and tested it, it still looks good to me. ;-) r=dbragg
Dan, Don mentioned you were asking about whether "err" was initialized since the patch didn't provide enough context. The answer is yes, "err" is already initialized to 0 which means OK. Hope this answers your pending query and we can bump this up to rtm+ once you super review the patch (assuming the rest of it looks OK to you). Thanks.
I'd like to give sr=dveditz, but just noticed this is in the mozilla tree where I can only give moa=dveditz.
Whiteboard: [rtm need info] → [rtm+]
Dan, can you ask PDT to put this one in the limbo list?
Still needs a sr=
Sent for sr to mscott earlier today. To expedite the sr process I have sent a second request, this time to brendan.
This bug is in candidate limbo
Provided OK is 0, sr=brendan@mozilla.org (http://lxr.mozilla.org/mozilla/source/xpinstall/wizard/unix/src2/nsWelcomeDlg.c pp#116 should initialize err to OK, not to 0, for symbolic constant purity). /be
rtm++, please land on branch ASAP.
Whiteboard: [rtm+] → [rtm++]
Brendan, OK is 0. I was tempted to set err = OK instead of err = 0 but wanted to keep the number of lines in the patch to the bare minimum required.
Whiteboard: [rtm++] → [rtm+]
Changing to rtm++ to match selmer's comment -- I assume this was an oversight
Whiteboard: [rtm+] → [rtm++]
Fix checked into branch and trunk. (Dan, thanks for watching the trees!)
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I verified this in 2000-11-02-09MN6 and 2000-11-02-08Mtrunk Linux build.
Status: RESOLVED → VERIFIED
cc: gbush/junruh. We should double check license agreement is still ok in the US builds.
Lisa, I use US build to verify this. The difference was that I found this bug in the Japanese locale setting. I just want to make clear.
Teruko, Thanks for verifying this with the ja_JP locale. Can you take a minute to confirm that we haven't regressed on an en_US locale system?
I verified this with US locale in 2000-11-02-09MN6 and 2000-11-02-08Mtrunk Linux build.
Samir, Xianglan and I tested this in Redhat 6.0 with Ja and ja_JP locale. License agreement dialog does not contain anything in Redhat 6.0. This works fine in 6.1 above. I reopen this bug. I think we support Redhat 6.0, right?
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I suggest we relnote it if the fix couldn't make it in time.
Actually, per bug 58259 some xheads (akkana, mcafee) have cited that we require RedHat 6.1 as the minimum supported version so this may be a moot point. Teruko, please attach the install log per our phone conversation. Thanks.
Status: REOPENED → ASSIGNED
I wouldn't worry about 6.0 now. We can release note this and point users to the about page to read the license after they've installed.
yes, open source software users are supposed to keep up with latest release. Since it is very unlikely that PDT will take any fix now, relnote is probably what we can resort to now.
Restoring fixed status since it works for RH 6.1+. We apparently don't support RH 6.0 anyways. Added relnoteRTM keyword so that it can be documented that the license file will not display in the Linux installer on RH 6.0 systems using a Japanese locale.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Keywords: relnoteRTM
Resolution: --- → FIXED
Verified as fixed.
Status: RESOLVED → VERIFIED
Reopening. see http://bugzilla.mozilla.org/show_bug.cgi?id=158139
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
This is reproduciable with 7-18 branch Linux build on Redhad 6.1 JA.
It is also reproduciable with 7-18 branch Linux build on Redhad 7.1JA.
This bug was a fix involving freeing memory buffers, you've reopened it due to a bug that claims punctuation symbols break things. That's two different bugs, so I'm reclosing this one.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 23 years ago
Resolution: --- → FIXED
I think this should be reopened, based on reading the orginal problem report, which states that "the license agreement dialog does not contain anything". I beleive that is still the case, and as such this bug hasn't been fixed as mentioned in comments 36, 37 and 38. If you are saying the original bug reporter should write an exact duplicate of this bug report to get another issue related to this problem fixed, then wouldn't that new bug be marked as a dup of this one?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Changed QA contact to ruixu@netscape.com.
QA Contact: teruko → ruixu
Bug http://bugscape.netscape.com/show_bug.cgi?id=15908 is tracking the same issue, so close this one.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Mark bug as VERIFIED.
Status: RESOLVED → VERIFIED
I'm reopening this bug as Bugscape is for Netscape bugs, not Mozilla bugs.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
But this originally fixed-in-Mozilla-long-ago bug was only reopened because of the recent Netscape-only change. Closing again.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
My apologies. When I see an open Mozilla bug, I assume it's a bug in Mozilla. And that bugs in Netscape reside over on Bugscape.
VERIFIED.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: