Open Bug 5704 Opened 25 years ago Updated 3 months ago

[AppleEvents] support the DoJavascript() appleevent

Categories

(Core :: XUL, task, P3)

Product:
Core
Component:
XUL
Platform:
Unspecified
macOS
Type:
task

Tracking

()

Milestone:
Future

People

(Reporter: mcmullen, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted)

Priority: P3 → P1
Target Milestone: M6
Accepting
QA Contact: 3853 → 4250
Assignee: mcmullen → rickg
Status: ASSIGNED → NEW
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.
Assignee: rickg → vidur
Just to put this on your radar.
Assignee: vidur → brendan
Target Milestone: M6 → M9
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.
Status: NEW → ASSIGNED
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.
Target Milestone: M9 → M10
M10, and I need Mac help.

/be
QA Contact: mcmullen
Simon Fraser has volunteered to help with Mac issues.
Target Milestone: M10 → M15
Priority: P1 → P2
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?
Priority: P2 → P3
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?
Summary: Apprunner should support the DoJavascript() appleevent → [AppleEvents] Apprunner should support the DoJavascript() appleevent
*** 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
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
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.
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?

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.
Target Milestone: M18 → Future
adding helpwanted keyword
Keywords: helpwanted
Blocks: 125419
2.5 years later...

ping?
OS: Mac System 8.5 → MacOS X
Summary: [AppleEvents] Apprunner should support the DoJavascript() appleevent → [AppleEvents] support the DoJavascript() appleevent
*** 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.
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 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)
Assignee: jag → nobody
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)

I've been trying to move my workflows away from Chrome before Google breaks uBlock Origin and am surprised that Firefox remains such a poor macOS citizen after 21 years. DoJavascript is supported by the other major browsers and is an important accessibility feature. This omission, along with no support for macOS services in the contextual menu #1284890, are unfortunately deal breakers for me.

Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 5 duplicates.
:enndeakin, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(enndeakin)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(enndeakin)
Type: defect → task
Hardware: PowerPC → Unspecified
You need to log in before you can comment on or make changes to this bug.