Last Comment Bug 293322 - (automator) Automator Actions
(automator)
: Automator Actions
Status: NEW
: helpwanted
Product: Firefox
Classification: Client Software
Component: Shell Integration (show other bugs)
: unspecified
: PowerPC Mac OS X
: -- normal with 19 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://developer.apple.com/macosx/aut...
Depends on:
Blocks: macmeta
  Show dependency treegraph
 
Reported: 2005-05-07 21:57 PDT by Ben Goodger (use ben at mozilla dot org for email)
Modified: 2010-02-02 20:13 PST (History)
33 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Ben Goodger (use ben at mozilla dot org for email) 2005-05-07 21:57:26 PDT
Firefox should at least support the same set of Automator actions that Safari
supplies, and maybe some more.
Comment 1 Jason Reich 2005-05-08 03:30:49 PDT
The current automator actions included in Safari are;
- Get Current Webpage = Gets the URL of the page currently being viewed
- Get Specified URLs = Allows the entry of URLs
- Display Movies = Displays video files in Safari (not sure how necissary this is)
- Display Webpages = Obviously, display said URLs in browser
- Download URLs = Downloads said URLs
- Filter URLs = Allows a list of URLs to filter based on text in entire URL or
parts of it
- Get Image URLs from webpage = Extract a list of all images on the specified
URL either embedded into the page or linked to the page.
- Get Link URLs from webpage
- Get text from webpage

In addition to these I think we need ones that can;
- Extract the text from a pre-specified object on a webpage (selected by ID perhaps)
- Extracting information from RSS feeds
- Selecting bookmarks and the URLs from them
- Bookmarking pages

Plus I think some kind of menu in Firefox where you can execute these workflows
and perhaps even assign function keys would be very useful.
Comment 2 Jean-Marc Desperrier 2005-05-08 11:00:40 PDT
I think the basic implementation should be a core element, that can then be
invoked in several ways, Automator on OSX, but -remote on Unix
(http://www.mozilla.org/unix/remote.html), so the work would benefit several
platforms.
Comment 3 Jason Reich 2005-05-08 15:40:36 PDT
(In reply to comment #2)
> I think the basic implementation should be a core element, that can then be
> invoked in several ways, Automator on OSX, but -remote on Unix
> (http://www.mozilla.org/unix/remote.html), so the work would benefit several
> platforms.
> 

If a set of shell commands could be developed it looks like it would be
extremely easy to make Automator actions that can control them assuming that a
standard for information transfer is decided. Maybe something like XML-RPC or
SOAP, or do you think those are too complicated?
Comment 4 Steven Marshall 2005-05-09 01:22:43 PDT
(In reply to comment #0)
> Firefox should at least support the same set of Automator actions that Safari
> supplies, and maybe some more.

It's probably better to emulate the scripting capabilities of OmniWeb
(http://www.omnigroup.com/applications/omniweb/) rather than Safari - Safari
isn't really renowned for it's scriptability, unlike OmniWeb. 

For example, Safari doesn't support very much in terms of native tab scripting -
one must resort to GUI scripting to get any info about non-active tabs...

John Gruber explains this best in his (albeit slightly outdated) OmniWeb 5 Beta
"review" (under the heading "AppleScript Support"):
http://daringfireball.net/2004/02/omniweb_5_public_beta

(From http://daringfireball.net/2004/02/omniweb_5_public_beta)
> There was one other flaw with [Safari's scripting] — Safari provides no 
> scripting access to tabs.
>
> OmniWeb 5 does, and it’s pretty sweet.
>
> The dictionary terminology is good: browser windows are browsers, which can 
> contain multiple tabs. Each tab has an address property. The release notes 
> state that scripting support is incomplete (e.g., tabs lack a title property, 
> alas), but what’s already implemented in beta 1 is more than Safari 1.2 
> offers.
> [...]
> You simply can’t do this in Safari, unless you avoid using tabs, because 
> Safari only offers scripting access to the URL of the frontmost tab in each 
> window. 
> Mac OS X’s GUI Scripting is not an acceptable workaround — even if you ignore 
> the fact that the syntax is horrendous, it requires taking over your actual
> GUI to do its thing.

I checked this morning, and none of this has changed in either the latest
(public) version of OmniWeb or Safari (on Panther, at least).
Comment 5 Jason Reich 2005-05-09 03:55:13 PDT
(In reply to comment #4)
> It's probably better to emulate the scripting capabilities of OmniWeb
> (http://www.omnigroup.com/applications/omniweb/) rather than Safari - Safari
> isn't really renowned for it's scriptability, unlike OmniWeb. 
>
Are there OmniWeb automator actions yet?

While it would be nice to have the full functionality of OmniWeb's scripting, I
think it is important to have Safari compatibility first. It can then be
extended to have omniweb style later.

What does everyone else think?
Comment 6 Steven Marshall 2005-05-09 04:16:29 PDT
(In reply to comment #5)
> Are there OmniWeb automator actions yet?

Unfortunately not, to my knowledge. I was referring more generally to it's
scripting capabilities through AppleScript.
 
> While it would be nice to have the full functionality of OmniWeb's scripting, I
> think it is important to have Safari compatibility first. It can then be
> extended to have omniweb style later.
> 
> What does everyone else think?

I agree totally, I just feel it may be better to consider long term options as
well, rather than hacking in Automator support and then having to massively
re-engineer it later to support other technologies (like AppleScript).
Comment 7 Jason Reich 2005-05-10 07:26:39 PDT
How about these sorts of commands for the command line -remote option? Feel free
to add any or say how rubbish they are.

======================
Command List

ListWindows() = Returns a list of Window References
ListTabs(WindowRef) = Returns a list of Tab References inside the window referenced
GetCurrentWindow() = Returns the reference of the last activated window
GetCurrentTab(WindowRef) = Returns the reference to the active tab in the window
referenced
NewWindow() = Returns the reference to the newly created window
NewTab(WindowRef, Active?) = Returns the reference to the newly created tab
GetTabInfo(TabRef, WindowRef, InfoType) = Returns request information
OpenURL(TabRef, WindowRef, escaped URL) = Returns nothing
ExtractImageURLs(TabRef, WindowRef, Embedded?OrLinked) = Returns a list of URLs
ExtractLinkURLs(TabRef, WindowRef) = Returns a list of URLs
ExtractText(TabRef, WindowRef) = Returns text

=====================
InfoType Enum

0 = Title
1 = URL
2 = Active?

=====================
Comment 8 Matthias Wallner 2005-05-10 08:38:12 PDT
dont you think, that FF should have a general Scripting support for all OS's and
not just Automator?
Comment 9 Benjamin Smedberg [:bsmedberg] 2005-05-10 08:51:17 PDT
How do automator actions return data back? Using the commandline handling system
to return data back on stdout or some other location would need lots of work,
since our builds tend to dump interesting garbage on stdout (especially when the
dump pref is enabled).
Comment 10 Jason Reich 2005-05-10 08:52:31 PDT
(In reply to comment #8)
> dont you think, that FF should have a general Scripting support for all OS's and
> not just Automator?

Somebody has already pointed that out in comment #2.

The way I interpreted the conclusion was that we would use the old mozilla
-remote command line parameter as a general scripting interface on top of which
we can put any OS specific ones.
Comment 11 Jason Reich 2005-05-10 08:56:41 PDT
(In reply to comment #9)
> How do automator actions return data back? Using the commandline handling system
> to return data back on stdout or some other location would need lots of work,
> since our builds tend to dump interesting garbage on stdout (especially when the
> dump pref is enabled).

Ah... i didn't think of that. Perhaps if we enclose any return with
	[Remote Response]:
        http://www.google.com
        [End]
or something easy to parse. Then we can have [Remote Error]: for error messages.
Any better alternatives?
Comment 12 Simon Spiegel 2005-05-11 00:08:56 PDT
> dont you think, that FF should have a general Scripting support for all OS's and
> not just Automator?

I'm not a programmer, so I don't know how you can achieve cross platform
scripting support. But IMO scripting is one of the areas where Firefox' is very
weak compared to other OSX browsers. For years I wanted to have AppleScript
support in Firefox/Mozilla. Netscape 4.x had terrific AppleScript support but
this functionality never came back. Please include Automator support, and while
you're at it also add proper AppleScript support.
Comment 13 Matthias Wallner 2005-05-11 01:48:55 PDT
(In reply to comment #12)
> > dont you think, that FF should have a general Scripting support for all OS's
and not just Automator?
> 
> I'm not a programmer, so I don't know how you can achieve cross platform
> scripting support.

Well, just add(*) Scripting functions directly into the Core and allow Automator
to use them. 
IMO if we want the mozilla apps to be scriptable, it should be possible to
script every part of it (but there may be security related issues with scripting
 stuff like XPI installation)

On the other hand, i never had the desire to script my Browser or Mail Client... 

(*) yes, i know its a little more then "just add it"
Comment 14 Deerwood McCord Jr 2005-05-21 21:04:34 PDT
Applescript is the best way to go. Initially implementing the DoJavascript and
cleaning up the Applescript Dictionary to provide english equivalents for the
window objects that are available.

Firefox has basic get GetURL actions already. A completed DoJavascript
applescript event (executing in Bookmarklet context) would go along way towards
Automator. This Event would need to return objects like Apple's DoJavascript
does. It's already stubbed in the code. but not implemented.
Comment 15 Ryan 2006-05-25 08:31:09 PDT
To whom it may concern,

I'm a Mac user (with some PC development background) just getting into Automator (among other OS X Tiger developer tools) and would benefit from (and greatly enjoy) the development of Automator actions similar to those for Safari. As you know, Automator comes with a select few Safari actions (e.g., "Get Current Webpage," "Get Image URLs from Webpage," "Filter URLs," etc.).

Other actions have since been in development, such as:
-Assert Attributes of Current Webpage
-Click Link or Button in Current Webpage
-Do Specified JavaScript in Current Webpage
-Set Form Values of Current Webpage
(See http://www.ottomate.org/automator/index.htm)


I know this lacks technical details, but I hope this helps you assess the interest and potential benefit to Firefox (and Mac) users.

Thanks,
Ryan
Comment 16 Jamie Wells 2006-05-31 02:53:13 PDT
I duplicated this bug by mistake because when I searched for Automator I searched only in bugs for Camino.  I searched there because Camino is billed as OS X specific build of Firefox with OS X only features and other OS integration.  I knew that Firefox was available for OS X, but I didn't download it because it wasn't as tightly tied in as Camino.  So, wouldn't it make more sense to talk about these features in terms of adding them to Camino, an OS specific build, instead of adding them to Firefox in general?  Or, am I reading this wrong and what you're talking about adding to Firefox (-remote) would make it easier to implement Automator Actions and still give some scripting support to other OSes?
Comment 17 Jamie Wells 2006-05-31 02:55:44 PDT
*** Bug 339696 has been marked as a duplicate of this bug. ***
Comment 18 Stuart Morgan 2006-05-31 07:52:10 PDT
Bug 339696 has been unduped--Camino is *not* an "OS X-specific build of Firefox". It's a different browser.
Comment 19 james.d.baker 2007-03-06 12:45:10 PST
It would be good if there was an set of Automator actions relating to the extension system so that extension authors could use Automator to automatically compile and install extensions when developing. I'd suggest perhaps the following actions:

Install/Update Extension
Disable/Enable Extension
Remove Extension
Restart Firefox
List Extensions
Get Extension Information
Comment 20 Alberto González Palomo 2008-06-21 16:09:15 PDT
Another useful action would be the equivalent of the command line option "-chrome".

In Windows and Linux I can start my extension from a custom desktop icon just by starting Firefox with that option: if Firefox is not running it's started, and in any case it opens the extension chrome window.

What happens in MacOS X is that it starts a new instance and asks me to select another profile.

The closest I've got is using OpenURL with a javascript URL, but apart from opening an extra window I met a security error when trying to open my chrome window with openDialog().

Note You need to log in before you can comment on or make changes to this bug.