Closed Bug 26265 Opened 25 years ago Closed 25 years ago

Profile manager fails because of string bundle loading failure

Categories

(SeaMonkey :: Startup & Profiles, defect, P1)

PowerPC
Mac System 8.5
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: agracebush, Assigned: bugs)

References

Details

(Whiteboard: [PDT+] will fix itself automatically when deps are fixed.)

Attachments

(2 files)

Installed moz build 2000020208 after deleting Mozilla Registry and profile 
folder
1. Create Profile Wizard is blank-UI ok but no text, buttons do not work except 
for cancel 
2. Profile Manager (bug 24911)
3. Select Profile shows no 4.x profiles for migration, does not allow 
new,rename,delete since no profiles can be created for selection

Workaround is to create 5.0 profile with older build - todays build will launch 
with that for testing
Summary: No ProfileManager functions work today → No ProfileManager functions work today
Putting on dogfood list.  
Keywords: dogfood
Select profile should NOT show 4.x profiles.

I think we need a profile meeting so we can all discuss 
- which profiles are displayed in which manager mode
- which regression bugs are regular breakages
- why these regressions are almost always due to back end changes (with the 
exception of a mistake in a WSM update yesterday, Alec and I apologise) and 
people not running the smoke tests before checking in their changes. 

Sorry to sound grumpy, its just that I'm spending so much time cleaning my bug 
list of repetetive, annyoing bugs that aren't mine that I'm finding it harder to 
get my real M14 work done.
Sounds good to me-the regressions are frustrating.
I am attaching a table that Bhuvan has posted to newsgroup that may clarify some 
issues.  I have been using -SelectProfile as a workaround to bug 24911.  A 
meeting would sort all this out.  Time?
cc'ing others keeping laurel in loop
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
M14.
Priority: P3 → P1
Target Milestone: M14
This isn't m14. This is something that we should hold the tree closed until it is 
fixed. Unless I am missing something this bug renders the product unusuable.
this appears to be working again in today's (0203) win32 builds (thank 
goodness). I'm going to check on Mac. 
Linux is successful for today(commercial tested)
Mac mozilla build and commercial build is not working except for one launch with 
an old profile. If I remove old profiles and registry I am unable to use 
product.  Seamonkey hangs with each try necessitating a reboot.
okay so we still suck on mac. this is really leading me to believe this isn't 
something I've done, or am able to fix ;)

symptoms today (02/03/00) are as grace described yesterday, Create Profile 
Wizard appears with a blank content IFRAME, as a result the JS code that manages 
the wizard buttons fails, and the only function that works is "Cancel". Creation 
of a profile is thus impossible.

The other problems are related to the Manager, yesterday no profiles appearing, 
and the "Manage Profiles..." button on the selection page being non functional.

I have not been able to try this today as the browser will not get past the 
splash screen. 
marking blocker, profiles are relatively important.
Severity: normal → blocker
Keywords: smoketest
okay so this is still the string bundle thing. reopened 25283
Depends on: 25283
does -P work to select an existing profile?
when i click on any button in the dialog, i get:

JavaScript Error: TypeError: this.wizardMap[this.currentPageTag] has no 
properties
URL: chrome://global/content/wizardHandlerSet.js
LineNo: 67

pull from 1:25pm 2/3/00.
I haven't seen if anybody else has complained about context menus being broken 
today, but I suspect it is due to the same thing as this bug.  The JS code in 
navigator.xul that interfaces with the nsContextMenu.js code produces JS 
TypeErrors like the one cited here.

I can't see any navigator.xul changes that would cause this.  Perhaps it's some 
sort of JS context thing (e.g., JS handler in the xul are executing in a context 
that can't see the JS context that holds the functions/vars)?
On commercial build (mac) I see this:
calling loadpage...
startPage:: newProfile1_1
JavaScript Error: uncaught exception: [Exception... "Component returned failure 
code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]"  
nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://
global/content/wizardManager.js :: WM_ProgressUpdate :: line 167"  data: no]

warning: property script.31 already exists
Update: Nobody else will see broken context menus 'cause it was due to a bug in 
JS code in my tree.  The odd thing is that this bogus JS didn't produce any sort 
of error to the console.

I suspect there's a JS syntax error in the code pulled into the profile manager 
xul and we're just not seeing any indicator to the console.
I did a post earlier but when I step through the code I am attempting to load 
"chrome://global/locale/wizardManager_en_US.properties" which seems really wrong 
to me but I am not that familiar with the string bundle code. I don't think it is 
a JS script error. I think it is a problem in that the given string doesn't exist 
in the loaded string bundle ( which might not be a real string bundle) and you 
get the NS_FAILURE exception. I would guess a try and catch might allow you to 
work around this but I haven't tried that yet.
Adding dependency on the synchronous loading bug, 26291
Depends on: 26291
*** Bug 25283 has been marked as a duplicate of this bug. ***
Summary: No ProfileManager functions work today → Profile manager fails because of string bundle loading failure
No longer depends on: 26291
Depends on: 26291
I don't get. What would you load 
"chrome://global/locale/wizardManager_en_US.properties" instead of 
"chrome://global/locale/wizardManager.properties". The real path is converted
by chrome registry.
The issue here is that the string bundle code is trying to do synchronous loads 
on the UI thread. This is not allowed in Necko, and results in the kind of 
failures seen here. This is described in bug 26291.
Never mind, there is no locale name embedded in the path to the property file. 
I'll take a look at stringBundle.
One question: if synchronous load is the problem, how come this problem does not 
appear on Linux nor WIN32? 

I don't have Mac here and would like to reproduce the problem on WIN32 or Linux.

Thanks
The bug is apparent only on Mac because of differences in threading/event 
handling issues in necko between platforms. These differences are a necesasry 
side-effect of the way that threading and event handling work on the different 
platforms.
Attached file StringBundle patch
Hi, Mac developers:


Would you please try out the patch and let me know if the problem goes away?
I tested the patch on NT; didn't break anything and improve the performance 
a bit. Don't have a Mac here.



Thanks
What does that patch do? It's not obvious to me how it changes the load from 
being synchronous to async. I also note these other problems with nsStringBundle:
1. It uses a mixture of nsString2 and nsString. This is redundant. In nsString2.h
   is
   #define nsString2     nsString

2. The nsStringBundle ctor does a lot of work, much of which can fail. You
   cannot propagate errors back from the ctor, so these errors are being
   unhandled. You should move this code to an Init() method.
The patch takes out the unnecessary fallbacks that cause strres check two files
that do not exist before getting hold of the third one that does exist.

How is the patch? Does the problom persist?

As to the coding style of this class, the nsString2 are residue of the nsString 
to nsString2 transition. The ctor thing is inherited from the old code base.
I agree that we need to fix it, though. I'll do it in fixing this bug.

Thanks for the info. 
Add tao to CC list
This isn't really blocking the tree, removing blocker severity and smoketest
keyword.
Severity: blocker → critical
Keywords: smoketest
I tried the patch on a fresh tree pulled around noon. Before the patch, Porfile
manager hangs after the stringbundle error in the console. After the patch, it
successfully proceed to next screen and start up the Mozilla browser.

If there is no objection, I'll check in the patch after getting review. Any 
volunteer for reviewing the patch? It is a simple change..... I tested it on 
NT and no abnormalty observed.
That patch does appear to fix the problem; it looks good.
OK, if you don't mind. I'll check it (w/ r=sfraser) in the weekend or next 
Monday unless someone would like to check it in for me. I got to leave 
earlier today.

Thanks
The patch appears to remove the code that tries a couple of non-existent files
before trying the existing one. I don't understand why that would hang the Mac,
though. Is that a peculiarity of Necko's file-handling code?

Also, do we still need to change StringBundle so that it loads the bundle
asynchronously? Does it have to be async even if the file is local? Async
loading may not solve any problems, since the app may be trying to get a string
from the bundle after trying to load it. So the app would have to be blocked at
that point anyway. I suppose we could try to avoid that blockage by spinning
several threads at app init time to load the bundles asynchronously. Hopefully
the bundles will have arrived by the time the app needs them. I don't know
whether such init time loading would be a performance hit though.

Tao, please use cvs diff -c (context diff). It is much easier to read.
> The patch appears to remove the code that tries a couple of 
> non-existent files before trying the existing one. I don't understand 
> why that would hang the Mac, though. Is that a peculiarity of Necko's 
> file-handling code?

Yes, although necko is behaving properly, even on Mac. Sync loads are just not
supported.

> Also, do we still need to change StringBundle so that it loads the 
> bundle asynchronously?

Yes. See bug 26291.

> Does it have to be async even if the file is 
> local?

Yes

> Async loading may not solve any problems, since the app may be 
> trying to get a string from the bundle after trying to load it. So 
> the app would have to be blocked at that point anyway. I suppose we 
> could try to avoid that blockage by spinning several threads at app 
> init time to load the bundles asynchronously. Hopefully the bundles 
> will have arrived by the time the app needs them. I don't know 
> whether such init time loading would be a performance hit though.

This is certainly a problem at startup time, when there is no event loop yet.
I think the solution may be for you to have your own event loop, in which you
spin until async loads are complete. Perhaps necko should provide such a 
facility.

If StringBundle had its own event loop, that event loop would receive UI events,
right? These would then be dispatched to the widgets and the app, but the app
might be in some state where it can't really process such events, since it might
be in the middle of its attempt to create the StringBundle.

I'm confused. But it doesn't seem like embedding an event loop in StringBundle's
constructor is going to solve our problem. I think we may unfortunately have to
impose the restriction on the caller that it must implement a callback with
StringBundle, which gets called back when the bundle has finished loading
asynchronously, as I mentioned in bug 26291.
>Yes, although necko is behaving properly, even on Mac. Sync loads are just not
> supported.

I don't get. How does expat loads external DTD files on Mac? DTD loading is still a synchronous op in expat as far as I know.
*** Bug 25571 has been marked as a duplicate of this bug. ***
*** Bug 26605 has been marked as a duplicate of this bug. ***
ctor initializing is bad and any potential failure cases need to be in an Init() 
method.

Async vs Sync:
I filed a dozen or so bugs on various pieces of the code that are doing sync 
loads. sync loads on the UI thread are illegal, however some people (rdf, 
xul) are knowingly breaking the law (and will get bit later if they ever start 
doing non-local file reads).

What works and what doesn't, and why. Sync reads of net based protocols on the 
UI thread will deadlock the UI thread, there will be no other adverse behavior, 
the UI thread will just block forever. This is because of the way our net 
protocols (obvioulsy more complex than file accessing) read data. They require 
an event to be processed on teh UI thread (which can't be processed if it's 
blocked). This behavior is largely dependent on the platform's underlying event 
handling implementation.

I've looked at making the string bundle stuff async. It's far from pretty. So 
ugly in fact that I've (very reluctatnly) suggested that necko fix it's protocol 
handlers to permit UI thread sync reading. Sync reading is bad in our 
current world. Unfortunately the code has progressed beyond the point of no 
return wrt sync vs. async models in several areas.

With that said, sync reading is *not* (or at least hasn't been) a problem with 
file based protocols (chrome:, resource:, file:). If the string bundle stuff is 
*only* using these protocols right now, then this bug is occuring for some other 
reason.
Jud, thanks for taking the time to look into StringBundle, and to write lengthy
comments here.

First, I completely agree that we should move StringBundle's constructor (ctor)
code to an Init method. This should be done *anyway*, perhaps in a separate
bug report?

Secondly, if XUL is knowingly breaking the rules by reading files synchronously,
then I would strongly suggest that StringBundle also break the rules for now.
As Jud said, getting StringBundle to "play nice" in the async rules world is
very ugly. We are not at the point in this project (near beta) to make changes
like this.

Finally, if the Mac is having problems with synchronous file reading, that ought
to be fixed separately. How can XUL work on the Mac if it can't handle sync file
reads???
At this point I don't think this particular problem is sync read related (unless 
you guys are reading bundles from the net). I'm not sure of the XUL details. 
There are some instances when XUL is loaded over the net (via the appropriate 
async mechanism) and sometiems it's loaded from disk (via sync :( )
As far as I am aware of, the only syc. loading related to XUL are *.dtd and
*.properties. They are all from the local disk (using resource protocol).
Just checked in the patch. Shall see it te result on 02/08/2000 build.
Whiteboard: [PDT+] → [PDT+] will fix itself automatically when deps are fixed.
Hi, Grace:

I believe this bug had been fixed in the current build. 


Hi, Ben:


Would mark it fixed so QA can verify it?




Thanks
Remove bug 26291 from the dependency list.
No longer depends on: 26291
this does indeed appear to be working now. thanks, tao!
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This is happening again. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
In a debug build or release build? What do you see in the console? Which day's 
build?


Thanks
this is another bug. I forget the number but its related to cropping. 
re-closing. 
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
build 2000021112
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: