202072 - No response to remote AppleEvents ("Cannot find process on host")

Status: RESOLVED EXPIRED

(SeaMonkey :: General, defect)

Description

[lyle]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312

Version 1.01 would respond nicely to the "activate" and "OpenURL" Apple Events
from a remote Mac (at least when both were running Mac OSX 10.2.4 or .5). Now
when I try this, I get an error message: "Mozilla got an error: Cannot find
process on host".

This works when tried from the same Mac upon which Mozilla is running.

Does not appear to be related to Bug 197643.

Sample AppleScript [works with 1.01, with "iCab" (2.8.2), "Opera" (6), "OmniWeb"
(4.2), "Netscape" (7.02), "Internet Explorer" (5.2) substituted for "Mozilla"]:

set remoteMac to "eppc://192.168.0.4"
set theURL to "http://www.apple.com/" as string

using terms from application "Mozilla"
	tell application "Mozilla" of machine remoteMac
		activate
		OpenURL theURL
	end tell
end using terms from

Mozilla doesn't even activate. If you edit the right (wrong?) line, you get an
error message about not being able to get the applications dictionary, which
means it may be related to bug # 184449.

Reproducible: Always

Steps to Reproduce:
1. Write an AppleScript that attempts to have Mozilla, running on a remote Mac,
activate, load a URL, or whatever.
2. Get it working using an earlier version of Mozilla (1.01 works)
3. Try to run the AppleScript against 1.3

Actual Results:  
AppleScript error message: "Mozilla got an error: Cannot find process on host".

Expected Results:  
activated, loaded the URL, i.e., what the AppleScript told it to do.

Comment 1

[Darin Fisher]

-> gordon

Comment 2

[Simon Fraser [no longer active]]

Do remote Apple events work with other Mach-O (bundled) applications?

Comment 3

[Greg K.]

[e-mail], your example script doesn't seem to compile.

Comment 4

[lyle]

You are right. It does not compile under 1.3! Rats. But it does under 1.0.1. So
I just compiled it under 1.0.1 and ran it trying to get 1.3 to do things on
another Mac. The Script Editor can't open the dictionary of 1.3. This may be the
root of the whole problem, or just an unrelated impediment to script writing.

Comment 5

[Greg K.]

[e-mail], what do you mean, "compile under 1.3" or "compile under 1.0.1"?
Those sound like Mozilla versions, and Mozilla certainly doesn't compile
AppleScript code.

The Script Editor application is what I'm talking about. It complains about the
line "OpenURL theURL" saying "Expected end of line, but found identifier."

Comment 6

[lyle]

When I wrote "compile under 1.3" I meant "compile when the Script Editor has access to version 1.3 of Mozilla for the purpose of consulting its dictionary".

I find it odd you got the error you report. It sounds like the Script Editor doesn't know what to make of the OpenURL word. If you have another browser on your Mac (see the list in my original problem description), substitute its name for "Mozilla" in the AppleScript and see what happens.

Comment 7

[Steve Dagley]

Methinks bug #184449 is biting us here

Comment 8

[Simon Fraser [no longer active]]

Bug 202340 covers getting a dictionary for Mozilla.

Comment 9

[lyle]

I mentioned bug # 184449 in my original description, because of the obvious
problem with the dictionary. However, even if you compile a script (with a copy
of  Mozilla with a working dictionary handy for Script Editor's reference)
successfully, when you run it, trying to get Mozilla 1.3, running on another
Mac, to do something fails as described. By the time you do that, the dictionary
on the  local machine has already been used, and the script has been reduced to
Apple Events (four-letter codes) and bits of data. As I understand it, the
dictionary is irrelevant at that point. So I suspect there are two bugs, or I
don't understand how compiled AppleScripts work. It sure would be nice if it was
just one bug.

Comment 10

[benc]

-> camino

Comment 11

[Simon Fraser [no longer active]]

Not camino

Comment 12

[Simon Fraser [no longer active]]

Trunk.

Comment 13

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420