Issues with chrome.manifest when installed in path having japanese characters

[bhargava....@gmail.com]

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 . May be because of this i am getting white screen. Not sure why i am getting this error . I am using VS 2010 and character set is multi -byte . I also changed it to unicode but nothing changed.

Please suggest

[Benjamin Smedberg]

On 8/14/2014 7:15 AM, bhargava....@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

[bhargava....@gmail.com]

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.

[Benjamin Smedberg]

On 8/14/2014 9:08 AM, bhargava....@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

[g...@novadsp.com]

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.

_______________________________________________
dev-embedding mailing list
dev-em...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding

[Benjamin Smedberg]

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

[g...@novadsp.com]

> 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.