Just to put this on your radar.
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
Assignee: brendan → sfraser
Status: ASSIGNED → NEW
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.
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
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. ***
Target Milestone: M16 → M18
bouncing back to Brendan, if you need help from Simon, just holler
Assignee: sfraser → brendan
Status: ASSIGNED → NEW
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
Assignee: brendan → sdagley
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.
Assignee: sdagley → sfraser
Status: NEW → ASSIGNED
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?
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.
Target Milestone: M18 → Future
adding helpwanted keyword
2.5 years later... ping?
OS: Mac System 8.5 → MacOS X
*** 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. ***
*** 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.
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.
Assignee: sfraser_bugs → jag
Status: ASSIGNED → NEW
Component: Tracking → XP Toolkit/Widgets
QA Contact: jrgmorrison
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 firstname.lastname@example.org.
(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)
You need to log in before you can comment on or make changes to this bug.