Accepting

Supported now, er, or at least it almost is. It tries to open a new window, and initialize its content with a javascript:url. Unfortunately, we don's seem to support javascript: urls at present.

Just to put this on your radar.

Brendan is going to help out with javascript: URLs. I don't want to DUP this with my other javascript: bug (1646), but the bugs are related.

Moving all Apprunner bugs past and present to Other component temporarily whilst don and I set correct component. Apprunner component will be deleted/retired shortly.

M10, and I need Mac help. /be

Simon Fraser has volunteered to help with Mac issues.

If this is more important than I think it is, pls. let me know -- I'll get Mac help and fix it, just not before beta. /be

Is this related at all to what required for test automation in bug http://bugzilla.mozilla.org/show_bug.cgi?id=5117 ? if so it should bump up in priority to unblock some test automation work. if not lower priority is good. Mac guys?

Adjusting priority. /be

Simon, I would need Mac help for this anyway, so while I'm gone, can I leave it with you? If not, please mark it M16 and bounce it back to me. I'm trying to relieve mitchell of being bugged about brendan's M14 and M15 bugs. Thanks, /be

Yeah, this is mostly Mac work. I guess the hard part would be finding the right script context in which to run an event-supplied script.

Well, the calling code for this event is in. Now someone has to tell me how to execute some random JS in some context or other. Do we need to specify which JS context to run in? Should that come from a specific window?

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

be: can you answer my last question? I'll be running this AppleEvent in the context of the app. I can get the front window (if one exists). Do I need an existing JS context to exectute random JavaScript?

M18

bouncing back to Brendan, if you need help from Simon, just holler

I don't even have a Mac. Cc'ing Mac-enabled people, looking for sympathy. sdagley, are you interested? /be

I think sdagley said he'd do this -- I swear I heard him say so after that last round at the Outback the other Friday.... /be

Taking back. Here's what I need to do: 1. Get an nsIDOMWindow for the target window (use front window if null) 2. Get window._content somehow (gives back an nsIDOMWindow 3. QI that to nsIScriptGlobalObject 4. Call GetContext to get an nsIScriptContext 5. Use EvaluateString will some null args to get default behaivor. What are the security concerns here? Doing it this way means that the AppleScript event will have the privileges as well as scope of top-level script tags loaded in the current doc. cc mstoltz for input on the security considerations here. Mitch, please contact me if you need more info about this AppleEvent stuff.

I take all that back. Reading at the start of the bug, the way jrm was going to do this was to load the JavaScript as a javascript: url in a new window. This should ease the security concerns.

I think Brendan's take is that if the AE specifies a window it operates on that window and if it doesn't use the front window (or the hidden window if no windows are open). My opinion on the security issue is that we restrict the events to local ones assuming another app running on the user's machine already has access.

Well, loading a JS url in a window will always nuke the previous contents of the window no? So I think it doesn't matter which window it executes in. I'm tempted to just make a new window for each call.

Not that I know what someone would do with this capability but shouldn't/couldn't the JS in the URL operate on the specified window rather than just loading?

Please keep this in mind: when a javascript: URL is loaded in an existing window, the JS runs with the principal (in the trust domain) of the previously displayed page. This is to support 'bookmarklets,' javascript: bookmarks which can read and modify the currently displayed page. These are relatively safe since the user must explicitly bookmark a javascript: URL, switch to the target page, and then choose the bookmark. I suppose this is a similar situation; an AppleEvent would allow other applications to do the equivalent of a user's choosing a javascript: bookmark, right? And local applications are by definition trusted. There's no way to trigger an AppleEvent from an untrusted site over a network, is there? See bug 28387 for a related discussion (ignore the tangential flame war in the middle of the comments). I'm not sure where these AppleEvents are initiated from, or what that implies. Just bear in mind that JS URLs run with the privileges of the most recent document in that window. Even though loading the JS URL might blow away the previous document (it might not), the script still has access to the content of any page from the same host as the previous document. See bug 48723 (NS- confidential, sorry) for an illustration of this.

Normally, AppleScripts are run by user interaction on the machine. However, there are a couple of issues here: 1. There are plugins available that allow you embed AppleScript in a web page, and have it executed <http://www.royalsoftware.com/> 2. I *think* it's possible to run AppleScripts over TCP/IP if you have login access to another Mac.

Moving this to Future.

adding helpwanted keyword

2.5 years later... ping?

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

Francis, Helpwanted means no one currently working on the project has had the time or desire to implement this feature. If you really want it, I suggest you find someone who can implement it and pay or otherwise convince them to do it. You don't have to wait for us to do it; that's the beauty of open source.

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

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

What needs to happen to make something happen? This lack of javascript support has been in existence since 1999 and no-one is addressing it. Please look at http://www.apple.com/applescript/ safari/jscript.01.html. Five years is a long time to wait! (In reply to comment #32) > *** Bug 255677 has been marked as a duplicate of this bug. ***

David.Atherton@attglobal.net: well, you'll have to start coding. per comment 20, it looks like the plan was: 1. find the right window (or recognize that the script should run in a new window) 2. construct a url of the form: javascript:"string" where string is the apple event script (double quotes escaped using backslashes, backslashes escaped using backslashes) 3a. if you're using a preexisting window, call something like: window.content.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components .interfaces.nsIWebNavigation).loadURI(url_from_step_2,null,null,null,null) 3b. otherwise, call window.open(url_from_step_2); you'd of course want to convert this to c++. thankfully there's a fairly easy mapping from js to c++. i'd suggest you start by building mozilla on macosx and then finding (use lxr) the appleevent handling code. for help w/ the next steps, you'll probably want to visit irc.mozilla.org #developers.

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

(In reply to comment #35) > *** Bug 287447 has been marked as a duplicate of this bug. *** Any idea's when this feature is going to turn up ???, as I would love to support you in our installs ???.

(In reply to comment #36) > (In reply to comment #35) > Any idea's when this feature is going to turn up ???, ... Do you have a use case? How would you tell wether the feature has "turned up"?

Safari's implementation of this requires a document reference; I'm not sure how much harder that makes it.

(In reply to comment #37) > (In reply to comment #36) > > (In reply to comment #35) > > Any idea's when this feature is going to turn up ???, ... > Do you have a use case? How would you tell wether the feature has "turned > up"? At the minute, the only way I can tell if it has turned up, is getting a version and checking the Apple Script Dictionary that it has this capability manually. Although I guess there might be a programatic way of detecting whether this feature is available ??? (Not sure and would have to check). Although if you are going to add window reference's then this make's it more tricky I guess. As presently the only way I know a browser works is by checking the browser's version information from its plist and examing the default browser creator code to identify who. Does this mean, this feature will be coming soon, as like I say I would love to enable our installer to use Firefox.

(In reply to comment #39) > (In reply to comment #37) > > (In reply to comment #36) > > > (In reply to comment #35) > > > Any idea's when this feature is going to turn up ???, ... > > Do you have a use case? How would you tell whether the feature ... > At the minute, the only way I can tell if it has turned up, is getting a > copy and checking the Apple Script Dictionary O.K. Firefox has the Spyglass 'OpenURL' and a 'Get URL' Appleevent. > As presently the only way I know a browser works is by checking the > browser's version information from its plist and examing the default > browser creator code to identify who. Are we talking about the same thing? Are you asking for a 'Do Javascript' Appleevent and a 'Document' class like the Safari suite? If so, do you have a simple Applescript that works when sent to Safari. Perhaps we can make it work when sent to Firefox. This is what I had in mind when I used the term 'use case' http://c2.com/cgi/wiki?UseCase Is there (known to you) a technical reason why Firefox should not support the Safari suite?

> O.K. Firefox has the Spyglass 'OpenURL' and a 'Get URL' Appleevent. Yes those are the defaults one's, so that they launch a given URL. > Are we talking about the same thing? Are you asking for a 'Do Javascript' > Appleevent and a 'Document' class like the Safari suite? If so, do you have > a simple Applescript that works when sent to Safari. Perhaps we can make > it work when sent to Firefox. Yes I'm asking for "Do Javascript" functionality. An example of what I'm sending is tell application "Safari" get the do Javascript "%s" in document 1 end tell The %s, can be differen't javascript code, as we fire differen't code at the default browser. > This is what I had in mind when I used the term 'use case' > http://c2.com/cgi/wiki?UseCase I guess what you mean, is how is this being used ???, There is no URL as the installer we use is totally CD based and we add in extra functionality by doing remote javascript execution. > Is there (known to you) a technical reason why Firefox should not support the Safari suite? I'm not famiar with the firefox source base so I cannot tell you why it isn't support, but I would have though it would be reasonable straight forward, as all is required is to add in this apple event into firefox, send the text to the javascript engine, pick up the results and send it back to the calling app.

(In reply to comment #41) > ..., but I would have though it would be reasonably straight forward, > as all is required is to add in this apple event into firefox, send the text to > the javascript engine, pick up the results and send it back to the calling > application. I am inclined to agree with you. Consider yourself Project Manager for the Thomas Applescript Support in Firefox Project. The next step is to divide each of those four parts of the project into smaller parts, none of which is expected to take more than 15 minutes. I am using this script as the simplest example, which, when working will indicate at least some success. tell application "Firefox" do JavaScript "document.title" in document 1 end tell

Mark, are you able to download the source tree and compile it. You will need about 900 MB disk space for the sources and a further 1500 MB of disk space for build products. If you are like me and make a mess of things allow for a total of about 8000 MB, though it can be done in less. Instructions are at http://www.mozilla.org/build/mac.html and linked pages. If you already have fink and the Developer Tools then this is a straightforward process, though it will obviously take some time to compile all the files involved. If you are starting from scratch, then allow between three days and three weeks to get everything set up, tested and configured.

(In reply to comment #43) > Mark, are you able to download the source tree and compile it. You will need > about 900 MB disk space for the sources and a further 1500 MB of disk space > for build products. If you are like me and make a mess of things allow for a > total of about 8000 MB, though it can be done in less. > Instructions are at http://www.mozilla.org/build/mac.html and linked pages. > If you already have fink and the Developer Tools then this is a straightforward > process, though it will obviously take some time to compile all the files > involved. > If you are starting from scratch, then allow between three days and three > weeks to get everything set up, tested and configured. Sorry, but I cannot really do this development, as I'm fully overload with day job (It would be great if my employer would pay me to do this, but this won't happen :-( ) and then in evening I do gaming development. There's just no time, I'm happy to help out in testing purpose, and any basic development questions for this. Sorry, but I'm going to have to leave this for someone else to pick it up, I'm guessing somebody who know's Mac development and reasonable knowledge of this source could add this in a 1-2 days maybe, if no major restructuring is necessary.

Hi, I was wondering what the status of this issue ? Thanks Mark

Mark, the last substantive comment was yours, in April this year. Not enough people are interested in seeing the results of this bug's being fixed, so nobody is motivated to (for example) resolve the decision implied by comment 34 and its predecessors, and start coding. People who want to do some coding are far more likely to choose areas where there is some interest from users.

There is certainly interest from this user, although unfortunately my technical knowledge can't contribute much. I mentioned this omission in 1999 as I wished to use Mozilla (and now Firefox and Camino) with Alco Blom's excellent URL Manager Pro and Web Confidential on a Mac. These two apps work perfectly with current versions of IE, Safari and iCab. I am sure that Alco would be extremely cooperative in working out some solution. As I use these apps every day and would love to stop using Safari, I hope that this facility can be added to M, F & C. Alco's Email address is alco.blom@mac.com.

(In reply to comment #47) > .... I mentioned this omission in 1999 as I wished to use Mozilla (and > now Firefox and Camino) with Alco Blom's excellent URL Manager Pro and > Web Confidential on a Mac. These two apps work perfectly with > current versions of IE, Safari and iCab. I see your point. See comment 40 and comment 42 Are you able to follow the instructions in comment 43 (how else are your ideas going to get tested. Do have a 'use case' - a short Applescript program that does what you want? (You could test it against Safari)

I'd love to bring this back up, and see if we can implement it. Correct me if I'm wrong but all major browsers support this currently except Firefox.

(In reply to Sam Schooler from comment #49) > I'd love to bring this back up, and see if we can implement it. Correct me > if I'm wrong but all major browsers support this currently except Firefox. correct (2 years later)