244060 - xremote doesn't work on aviary branch

Status: RESOLVED FIXED

(Core Graveyard :: X-remote, defect)

Description

[Christopher Blizzard (:blizzard)]

Some stuff has changed related to the xre on the aviary branch that has broken
xremote.  This includes:

  const char *program = gAppData->appName;

this is "Firefox" instead of the normalized-to-lower-case "firefox" so scripts
will fail.  This was originally MOZ_APP_NAME from autoconf.  I'm ok with fixing
this down in the xremote code (i.e. normalize everything to lower case.)

Also, _MOZILLA_PROFILE is unset.  I suspect I just need to not set it if it's
zero length or null.  But we knew this problem was coming and discussed it earlier.

Comment 1

[Christopher Blizzard (:blizzard)]

Attachment: patch that lower-cases program names and makes sure they are both set

This just simply lower cases the program name and makes sure that both program
and profile are set to something other than a zero-length string.

Comment 2

[Benjamin Smedberg]

Comment on attachment 148858 [details] [diff] [review]
patch that lower-cases program names and makes sure they are both set

r+a=me for the aviary branch. get a sr before landing on the trunk (I hope to
land semi-single-profile on the trunk soon after 1.8a1)

Comment 3

[Christopher Blizzard (:blizzard)]

Committed on the branch.  Is there a keyword?

Comment 4

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 247754 has been marked as a duplicate of this bug. ***

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 148858 [details] [diff] [review]
patch that lower-cases program names and makes sure they are both set

Something tells me we want this on the 1.7 branch.

Comment 6

[Mike Kaply [:mkaply]]

Comment on attachment 148858 [details] [diff] [review]
patch that lower-cases program names and makes sure they are both set

a=mkaply

Are we sure xremote is broke in 1.7?

Comment 7

[Benjamin Smedberg]

I can't see any reason for this to be on the 1.7 branch...

Comment 8

[(not currently active) Ted Mielczarek]

Is bug 246166 a dupe of this?

Comment 9

[Brian Ryner (not reading)]

I checked this patch in on the trunk; it was not landed as part of the
semi-single-profile landing and hence this regression is present on the trunk.

Marking FIXED.

Comment 10

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

This broke XRemote ping() for me on the trunk.  With revision 1.39 of
XRemoteService.cpp and a running firefox, I see:

dbaron@darby Linux (2) /builds/trunk/obj/firefox-opt/dist/bin $ ./firefox
-remote "ping()"
dbaron@darby Linux (0) /builds/trunk/obj/firefox-opt/dist/bin $

(process returned 0, as it should)

With revision 1.40 of XRemoteService.cpp and a running firefox, I see:

dbaron@darby Linux (2) /builds/trunk/obj/firefox-opt/dist/bin $ ./firefox
-remote "ping()"
Error: No running window found
dbaron@darby Linux (2) /builds/trunk/obj/firefox-opt/dist/bin $

(return value was 2, which is wrong, and "Error: No running window found" was hit)

Comment 11

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

bryner fixed the above problem with a change to nsAppRunner.cpp

Comment 12

[David]

Firefox is okay, but Thunderbird is still affected.  (2004-09-03-04-0.8)

$ ./thunderbird -remote 'ping()' || echo $?
Error: No running window found
2
$ ./mozilla-xremote-client -a thunderbird 'ping()' || echo $?
./mozilla-xremote-client: Error: Failed to find a running server.
2
$ ./mozilla-xremote-client -a Thunderbird 'ping()' || echo $?
$

Comment 13

[Tuukka Tolvanen (sp3000)]

thunderbird aviary 20040914 still broken, bug 259305