Closed Bug 41005 Opened 24 years ago Closed 24 years ago

PSM needs help converting to client's I18N libraries.

Categories

(Core :: Internationalization, defect, P3)

defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: javi, Assigned: tao)

Details

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (WinNT; U)
BuildID:    200004278

PSM is going through the process of converting its libraries to that of Mozilla 
and running into problems with the nsStringBundle class.  


Reproducible: Always
Steps to Reproduce:
1.Download the zip file at 
http://cindercone/h/iridium/mccrel/nsm/nsm12/server/ships/20000529.1/smithers_So
laris2.5.1/security/nsm/server/20000529/domestic/SunOS5.5.1_OPT.OBJ/mdbinary.jar

(It says mdbinary.jar, but it's really just a zip file.)
2.Get a version of Solaris Mozilla and try to do any PSM created UI, like 
clicking on the lock icon in the lower right hand corner.


Actual Results:  PSM will crash because it can't load any of the strings from 
the properties files.

Expected Results:  A dialog for the Personal Security Manager should show up.


We have taken absnapshot of M14 to do our initial conversion to avoid the 
problems associated with trying to sync up with the moving target that is 
Mozilla.bbI'm encountering the followin problem.  When I run the libraries in 
debug mode, everything works great.  But when I use the optimized
components of the libraries, I cannot read any of the properties files. 

After extensive printf debugging, I've narrowed it down to this:  When reading 
in the properties files through the resource:// handler, at
some point in time an event gets posted to the nsThreadPoolRunnable event queue 
which goes off and reads the properties file from disk. 
(At least this is what happens in the debugged version.)  In the optimized 
version, the event to read from the disk never gets processed. 
I'm not sure if it's because the message never gets sent or if it's because the 
event happens way before the event thread happens. Must resolve this soon so 
that we can deliver a version of PSM for PR2 allowing enough time for 
stabilization.
*SPAM* - moving this bug to 'new' status to get it off the unconfirmed status
radar. Sorry for the spam
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hi, Javier:

Would you mind downloading the newest Seamonkey build to see if the problem 
persists? StrinBundle code had undergone a few changes to make it thread safe.


Please also test if the problem exists on other platforms such as Linux, Mac, 
and Win32.


Thanks
We had to choose a version of the libraries to do our work against.  Mozilla 
code base was moving far too much for us to stabilize against specailly since 
our deadlines were approaching.  The engineer who did this work chose to 
stabilize against the M14 branch.  So PSM runs with a binary drop of M14 
libraries.  It's those libraries that we are shipping against and it's those 
libraries we are seeing the problems with.  Downloading the latest Mozilla will 
not help us because it is not binary compatible with M14 libraries which PSM 
is trying to use right now.  

You didn't see this problem with M14 of Mozilla, so we should be able to use the 
same code.  Is there something we didn't do correclty?  View 
http://lxr.mozilla.org/mozilla/source/security/psm/lib/nlslayer/nlslayer.cpp to 
see how we've implemented our NLS layer.  If you see any glaring wrong-doings 
let us know.
Hi, Javier:

Couple of points:

1. 
One thing you can try is to grab recent code changes in mozilla/intl/strres and 
see if the problem exists with new code. You can rip out those added code that
is not related to your needs. Note that the threadsafe code is checked into by 
Alec F. You can also grab his change (through CVS) and apply it to the M14 
branch you are working on.

2. 
When StringBundle is not available, the caller should not just crash. It
shall deal with it gracefully, instead.

3.
At last, I notice that you marked platform and OS fields of this bug to "ALL". 
Does this mean you are able to reproduce the problem on ALL OS and platforms,
at least for Mac, Linux, and Win32? Reason for asking is that there are some
platform parity with threading related implementation which might be what 
you are seeing now.


Thanks
BTW, it's rather an i18n bug than l10ns's.
Component: Localization → Internationalization
In hindisght, I should have marked only Solaris as a platform.  I'm trying to 
build a Win95 version of psm to see if it has the same problem, but I'm running 
into different problems.

Are the relevant changes all in strres?
Yes, all the changes make stringBundle threadsafe is in intl/strres.

Hi, Javier:


How are you guys doing? Have you got any progress so far? Are yo still seeing
the problem after incorporating the new code change?
We got side-tracked somewhat from this.  The current plan is to move our code to 
the tip/M16 branch and see if that eliminates the problem.  Once we do that, 
I'll update this bug accordingly.
mark it "REMIND " until Javier resume is work on this.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → REMIND
This is actually fixed.  We moved to M16 libraries and the problems went away.

Sorry for not letting you know.
I will reopen it and mark it WORKFORME
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Per Javier's statement, mark it work for me.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.