Closed
Bug 284955
Opened 19 years ago
Closed 19 years ago
xulrunner 'simple' app string bundle warnings
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: darin.moz, Assigned: darin.moz)
References
Details
Attachments
(1 file)
3.95 KB,
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
xulrunner 'simple' app string bundle warnings on startup, i see the following warnings about string bundles not being loaded: Couldn't convert chrome URL: chrome://communicator/locale/layout/xmlparser.properties WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 250 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/parser/ htmlparser/src/nsExpatDriver.cpp, line 724 Couldn't convert chrome URL: chrome://navigator-platform/locale/navigator.properties WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 Couldn't convert chrome URL: chrome://navigator/locale/navigator.properties WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file c:/builds/moz-trunk/mozilla/intl/st rres/src/nsStringBundle.cpp, line 273 I suspect that the chrome: URL resolution warnings are the cause of the string bundle loading problems. This probably indicates that there is some build packaging problem or that we are missing some important files.
Assignee | ||
Updated•19 years ago
|
Comment 1•19 years ago
|
||
*** Bug 284954 has been marked as a duplicate of this bug. ***
Comment 2•19 years ago
|
||
The xmlparser.properties error is a "correct" error caused by some of ganalf's locale-moving. chrome://navigator* is not part of xulrunner at all (nor is it part of Firefox)... who is trying to load it? Does the app still start correctly, even with these warnings/errors?
Assignee | ||
Comment 3•19 years ago
|
||
Yes, it loads fine. These may be benign warnings. They certainly don't seem to matter for 'simple', but then again it hardly exercises the system. I'm going to take a closer look to see what is triggering the other URLs to be loaded.
Assignee | ||
Comment 4•19 years ago
|
||
Hmm... it looks like chrome://communicator/locale/layout/xmlparser.properties is hardcoded in nsParserMsgUtils.h. So, you say that someone is working on fixing that problem? Any idea if there is a bug on file that this one can depend on? It looks like chrome://navigator-platform/locale/navigator.properties comes from the localized value of the preference: "intl.charset.default", which is queried by DocumentViewerImpl::GetDefaultCharacterSet. Similarly, "intl.charset.detector" appears to resolve to chrome://navigator/locale/navigator.properties, which is queried by nsHTMLDocument::StartAutodetection. Those all seem like fairly important components. Firefox seems to override the default value of these preferences (listed in all.js) in its firefox.js. In Firefox they seem to resolve to chrome://global/ URLs, so perhaps I should do the same for XULRunner (i.e., create a xulrunner.js). Does that sound like the right solution to you?
Comment 5•19 years ago
|
||
> Any idea if there is a bug on file that this one can depend on? See bug 284428 and commentary ;) > It looks like chrome://navigator-platform/locale/navigator.properties comes from > the localized value of the preference: "intl.charset.default", which is queried > by DocumentViewerImpl::GetDefaultCharacterSet. > > Similarly, "intl.charset.detector" appears to resolve to > chrome://navigator/locale/navigator.properties, which is queried by > nsHTMLDocument::StartAutodetection. > > Those all seem like fairly important components. Firefox seems to override the > default value of these preferences (listed in all.js) in its firefox.js. In > Firefox they seem to resolve to chrome://global/ URLs, so perhaps I should do > the same for XULRunner (i.e., create a xulrunner.js). It depends on how expedient you want to be. all.js shouldn't list the seamonkey-specific locations, and intl.charset.detector should probably ship its own files (I don't know much about that). There are a whole slew of XXXbsmedberg comments in all.js about toolkit-dependent prefs that need love. But having a xulrunner.js is probably the expedient solution for 1.8 to avoid introducing unexpected regressions. --BDS
Depends on: 284428
Assignee | ||
Comment 6•19 years ago
|
||
This patch adds xulrunner.js, which fixes up various i18n/l10n-specific preferences accordingly.
Attachment #176534 -
Flags: review?(benjamin)
Updated•19 years ago
|
Attachment #176534 -
Flags: review?(benjamin) → review+
Assignee | ||
Comment 7•19 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•