Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 7:15 AM, bhargava.animes...@gmail.com wrote: I am using gecko SDK 28.0 in my application. When my application is installed in path having japanese/korean characters then in my embedded browser nothing is shown.We found following error in logs Could not read chrome manifest 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2%C3%AF%C2%BE%C5%A0%C3%AF%C2%BD%C2%B7%C3%AF%C2%BE%E2%80%9E%C3%AF%C2%BD%C2%B6%C3%AF%C2%BD%C2%BD%C3%AF%C2%BE%C2%9D%C3%AF%C2%BD%C2%B6%C3%AF%C2%BD%C2%B7.Debug/mozilla/chrome.manifest'. Could not read chrome manifest 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2%EF%BE%8A%EF%BD%B7%EF%BE%84%EF%BD%B6%EF%BD%BD%EF%BE%9D%EF%BD%B6%EF%BD%B7.Debug/chrome.manifest'. The actual path is 'file:///C:/Users/an/Elements/main/build/targets/x64/elements2ﾊｷﾄｶｽﾝｶｷ.Debug/chrome.manifest'. Inside the browser complete white screen is shown. I have components that need to be registered with chrome.manifest. Since i am getting this error , those components would also be not registering . This sounds like a bug, although it's not clear where exactly the bug is without further debugging. Windows is especially hard in this regard because the native codepage is variable and doesn't express the full unicode range, so internally we try to use wide characters or UTF8 to represent windows paths, but occasionally that fails. You should file a bug to track the issue, but unless you can construct a testcase where this bug affects Firefox, it's likely that you will need to do the debugging yourself. cc me on the bug and I can point you to the lines of code you should look at in your debugger. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
Re: Issues with chrome.manifest when installed in path having japanese characters
In our code , we are having following snippet :
rv = NS_NewNativeLocalFile(nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(libxul));
if (NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = NS_NewNativeLocalFile( nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(appDir));
if(NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = XRE_InitEmbedding(libxul, appDir, 0);
rv in each case is NS_OK . After execution of 'XRE_InitEmbedding(libxul,
appDir, 0); ' we are getting the chrome.manifest error. I have checked
filepath ( containing japanese characters) , it is correct.
Is there any other way by which we can register our JS and binary components ?
I'll log a bug separately and cc you.
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 9:08 AM, bhargava.animes...@gmail.com wrote:
In our code , we are having following snippet :
rv = NS_NewNativeLocalFile(nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(libxul));
if (NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = NS_NewNativeLocalFile( nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(appDir));
if(NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = XRE_InitEmbedding(libxul, appDir, 0);
rv in each case is NS_OK . After execution of 'XRE_InitEmbedding(libxul,
appDir, 0); ' we are getting the chrome.manifest error. I have checked
filepath ( containing japanese characters) , it is correct.
What character set is filepath, and what charset is the native
filesystem? Note that using narrow char* to store these is inherently
lossy, and you should probably be using char16_t*/WCHAR* for these so
that you don't run into issues with unicode repertoire: then you'd be
using NS_NewLocalFile not NS_NewNativeLocalFile.
--BDS
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
RE: Issues with chrome.manifest when installed in path having japanese characters
I am not sure if your problem is identical to one I recently had to solve.
XRE_InitEmbedding2Type on Windows uses ReadDependentCB() and TS_tfopen()
internally (implemented in nsXPCOMGlue.cpp. In the 2 helpers, which both
take char* parameters, the MultibyteToWideChar conversion used the CP_UTF8
flag. If your path contains MBCS double byte characters then this conversion
will produce garbage.
The 'fix' I used here was to was to call lcid() to get the current locale
and pass that value to MultibyteToWideChar instead of CP_UTF8. This works
when the correct locale is set (Region language) but will still fail if
you have mixed DBCS character strings.
I suspect the right thing to do here is actually modify the embedding API to
use wchar_t for filenames etc, which is how things are (correctly) handled
within the main codebase.
-Original Message-
From: dev-embedding
[mailto:dev-embedding-bounces+g4=novadsp@lists.mozilla.org] On Behalf Of
bhargava.animes...@gmail.com
Sent: 14 August 2014 14:09
To: dev-embedding@lists.mozilla.org
Subject: Re: Issues with chrome.manifest when installed in path having
japanese characters
In our code , we are having following snippet :
rv = NS_NewNativeLocalFile(nsEmbedCString((char *)filepath), PR_FALSE,
getter_AddRefs(libxul));
if (NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = NS_NewNativeLocalFile( nsEmbedCString((char *)filepath),
PR_FALSE, getter_AddRefs(appDir));
if(NS_FAILED(rv))
{
throw BALBrowserException();
}
rv = XRE_InitEmbedding(libxul, appDir, 0);
rv in each case is NS_OK . After execution of 'XRE_InitEmbedding(libxul,
appDir, 0); ' we are getting the chrome.manifest error. I have checked
filepath ( containing japanese characters) , it is correct.
Is there any other way by which we can register our JS and binary components
?
I'll log a bug separately and cc you.
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
___
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding
Re: Issues with chrome.manifest when installed in path having japanese characters
On 8/14/2014 9:58 AM, g...@novadsp.com wrote: I am not sure if your problem is identical to one I recently had to solve. XRE_InitEmbedding2Type on Windows uses ReadDependentCB() and TS_tfopen() internally (implemented in nsXPCOMGlue.cpp. In the 2 helpers, which both take char* parameters, the MultibyteToWideChar conversion used the CP_UTF8 flag. If your path contains MBCS double byte characters then this conversion will produce garbage. This is correct and intentional: see the comment at http://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXULAppAPI.h#155 We do this because on Windows the native charset doesn't represent unicode. So we use a wmain entry point and wchar, and convert to UTF8 immediately so that we can use a shared char* interface with all the other platforms. --BDS ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
RE: Issues with chrome.manifest when installed in path having japanese characters
This is correct and intentional: see the comment at http://mxr.mozilla.org/mozilla-central/source/xpcom/build/nsXULAppAPI.h#155 We do this because on Windows the native charset doesn't represent unicode. So we use a wmain entry point and wchar, and convert to UTF8 immediately so that we can use a shared char* interface with all the other platforms. Indeed, and this behaviour is (probably) the best to adopt. However it is a problem if the embedder is itself an MBCS application. ___ dev-embedding mailing list dev-embedding@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-embedding
