Xremote : Command line handling is broken for non-ASCII characters

RESOLVED INCOMPLETE

Status

()

Core
X-remote
RESOLVED INCOMPLETE
15 years ago
2 years ago

People

(Reporter: Simford, Assigned: Jungshik Shin)

Tracking

({intl})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
Steps to reproduce:
1.in terminal, start mozilla
2.If there is no mozilla process alive,type:
      mozilla http://nihao(type some Chinese words)
  then mozilla open with the Chinese url that is parsed 
  and displayed correctly in mozilla url bar.
3.If mozilla is running, repeat step 2, 
  the Chinese word parse changes to strange symbol.

Comment 1

14 years ago
Test case:

% ./mozilla
% ./mozilla-xremote-client "openurl(http://***********,new-window)"
(****** : type URL with multibyte characters)

The following printf function for debugging returns garbled characters.
(Please compare with the result of successful case by "./mozilla http://********")

docshell/base/nsDocShell.cpp#2497
NS_IMETHODIMP
nsDocShell::LoadURI(const PRUnichar * aURI,
                    PRUint32 aLoadFlags,
                    nsIURI * aReferringURI,
                    nsIInputStream * aPostStream,
                    nsIInputStream * aHeaderStream)
{

/** For debugging **/
nsAutoString tmpString(aURI);
printf("%s\n", NS_ConvertUTF16toUTF8(tmpString).get());

So, the variable of aURI seems to be invalid.
Does anyone know which function calls this LoadURI()?

Updated

14 years ago
Keywords: intl

Comment 2

14 years ago
The invalid value "aURI" is transferred from the following function.

nsresult
XRemoteService::OpenURL(nsCString &aArgument,
                        nsIDOMWindowInternal *aParent,
                        PRBool aOpenBrowser)
:
  nsString url;
  url.AssignWithConversion(aArgument.get());

:
    rv = webNav->LoadURI(url.get(), <=== This one.
                         nsIWebNavigation::LOAD_FLAGS_NONE,
                         nsnull,
                         nsnull,
                         nsnull);
(Assignee)

Comment 4

14 years ago
This might be a dupe (IIRC, I 've seen/filed a bug on X-remote. I even have a
partial fix in my tree). It's not simple to fix because Mozilla can run on a
remote machine under a locale different from that of a machine where the command
is issued. Everybody should use UTF-8 .... on Unix/Linux

Needless to say, the following is downright wrong. (we need to do tree-wide
search of AssingWithConversion and LossyCopyUTF16ToASCII and CopyASCIItoUTF16)

 > url.AssignWithConversion(aArgument.get());

However, just replacing the above with NativeToUnicode doesn't work in some cases.  
Summary: Chinese word parse to strange symbol if mozilla instance exist → Command line handling is broken for non-ASCII characters when mozilla is controlled via Xremote
Hmm... does xremote work across machines?  I didn't think it did.

If it does, we should do the charset conversion (to UTF16 or UTF8) on the
calling end, clearly.
(In reply to comment #5)
> Hmm... does xremote work across machines?  I didn't think it did.

oh yes, it does. as long as the $DISPLAY is the same.
(Assignee)

Comment 7

14 years ago
*** Bug 269613 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

14 years ago
Created attachment 174845 [details] [diff] [review]
first shot

This works as long as both client and 'server' are running where
XUTF8StringStyle is supported (they don't have to be on the same machine.
Neither do they have to be running in the same locale.)

Only '_MOZILLA_COMMAND' is translated in this patch, but '_MOZILLA_PROFILE' hsa
to be translated similarly.
Assignee: blizzard → jshin1987
Status: NEW → ASSIGNED
(Assignee)

Comment 9

14 years ago
One way to work around the interoperability problem is to add a property
(MOZILLA_COMMAND_PROP2 or something) of COMPOUND_STRING type. On the server-
side, UTF8_STRING (MOZILLA_COMMAND_PROP) is checked first. The second prop is
only retrieved when the first is not available. We can go even further by adding
a third prop of STRING type, but I guess we don't have to.

Summary: Command line handling is broken for non-ASCII characters when mozilla is controlled via Xremote → Xremote : Command line handling is broken for non-ASCII characters

Comment 10

2 years ago
Mass resolving a bunch of old bugs in the x-remote component in preparation for archiving it. If this bug is still valid and useful, please move it to the "Toolkit: Startup and Profile System" component and reopen it.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.