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

Putting on dogfood list.

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.

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.

okay so this is still the string bundle thing. reopened 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

*** Bug 25283 has been marked as a duplicate of this bug. ***

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.

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.

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.

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.

this does indeed appear to be working now. thanks, tao!

This is happening again. Reopening.

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.

build 2000021112