xulrunner 'simple' app string bundle warnings

RESOLVED FIXED in mozilla1.8beta2

Status

()

Core
Internationalization
--
major
RESOLVED FIXED
14 years ago
10 years ago

People

(Reporter: Darin Fisher, Assigned: Darin Fisher)

Tracking

Trunk
mozilla1.8beta2
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

3.95 KB, patch
Benjamin Smedberg
: review+
Details | Diff | Splinter Review
(Assignee)

Description

14 years ago
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

14 years ago
Blocks: 257162
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta2
*** Bug 284954 has been marked as a duplicate of this bug. ***

Comment 2

14 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

14 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

14 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

14 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

14 years ago
Created attachment 176534 [details] [diff] [review]
v1 patch

This patch adds xulrunner.js, which fixes up various i18n/l10n-specific
preferences accordingly.
Attachment #176534 - Flags: review?(benjamin)

Updated

14 years ago
Attachment #176534 - Flags: review?(benjamin) → review+
(Assignee)

Comment 7

14 years ago
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Updated

10 years ago
Component: XP Miscellany → General
QA Contact: brendan → general

Updated

10 years ago
Component: General → Internationalization
QA Contact: general → i18n
You need to log in before you can comment on or make changes to this bug.