Firefox should at least support the same set of Automator actions that Safari supplies, and maybe some more.

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.

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.

(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?

(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).

(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?

(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).

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? =====================

dont you think, that FF should have a general Scripting support for all OS's and not just Automator?

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).

(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.

(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?

> 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.

(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"

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.

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

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?

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

Bug 339696 has been unduped--Camino is *not* an "OS X-specific build of Firefox". It's a different browser.

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

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().