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.

-> gordon

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

lyle@mac.com, your example script doesn't seem to compile.

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.

lyle@mac.com, 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."

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.

Methinks bug #184449 is biting us here

Bug 202340 covers getting a dictionary for Mozilla.

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.

-> camino

Not camino

Trunk.

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

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