Bug 514108 explains why Firefox no longer supports the ancient "ptit" and "curl". Bug 363747 comment 9 shows the new way to get the title of the current page, but there's no new way to get the URL. Support for getting the current URL from Firefox was a flagship feature of Things 1.2.1, so it would be a shame if we broke that in Firefox 3.6. See http://culturedcode.com/things/blog/2009/08/things-12-fasten-your-keyboards.html and http://twitter.com/culturedcode/status/3690124540. <joshmoz> Jesse: its unlikely we'll fix it soon - I remember why we dropped it now and it is a pain <joshmoz> Jesse: what we support in 3.6 is through the standard scripting dictionary <joshmoz> Jesse: if we want to add other attribute access we have to publish a script dictionary for each app <joshmoz> Jesse: so such a thing doesn't belong in gecko proper, it needs to be part of particular apps <joshmoz> Jesse: Safari supports it, not WebKit, so if we want to do it then it is a Firefox thing, it needed to be removed from gecko

Is this what would fix the "Add URL from Minefield" in AddressBook?

Josh: how could we publish this as part of the Firefox app, then?

Can I get an answer to comment #2? Important to know in order to determine whether or not we can block on this. I agree with Jesse that it's very much wanted, but without knowing if it's doable to expose only at the browser level, can't block. Please renominate if we get new information here.

The answer isn't simple, its on my list of things to do this week.

First we need to find out what syntax we want to support. Whatever we choose should be as standard as possible and also work in Safari. Maybe something like this, which works in Safari: tell application "Safari" set URL of document 1 to "http://www.example.com/" get URL of document 1 as text end tell I don't really know what the deal is with documents lists and numbers, whoever does this will have to figure that out. It would be nice if whatever we pick also makes the Address Book functionality from comment #1 work.

For reference, our basic AppleScript support is in here: toolkit/xre/MacApplicationDelegate.mm We don't have a custom AppleScript dictionary, we might have to add one in order to support URLs.

Are there any updates to this issue? Being able to use AppleScript to get the current URL from Firefox is a key feature for our product "RescueTime". If Firefox 3.6 does not ship with this, it will be the ONLY browser on the OSX market that does not support this. From my standpoint, I don't care what the syntax is to get the URL, the Safari syntax suggested above would be great.

Josh, I'm busy with a static build but do assign this back if you feel you must.

Getting the current URL from Firefox is an important feature of my application, EagleFiler. Though undocumented, the "curl " property worked fine with Firefox 3.5. I would like to see this functionality restored.

I have a Kiosk application that is used at several events, including Macworld Expo. Being able to set and get the URL is essential to using Firefox in this environment. 3.6 is currently a no-go for me.

Hi there, I'm using CulturedCode Things and having lost the autofill function from Firefox is a real pain in the b*tt. Thanks anyway for the great job you're doing, guys, but a fix would be much appreciated by many of us. Cheers, JPH

Can we have this functionality restored as soon as possible please? This breaks the workflow of so many applications, that used to integrate nicely with firefox.

I can't say when we'll be able to fix this, but we understand that it is a desired feature.

This also broke my app, please fix ASAP!!

I was also puzzled after having updated to Firefox 3.6, and CulturedCode Things' autofill function not working anymore. This quite a inhibition of the workflow. Thanks for putting it back asap.

"I can't say when we'll be able to fix this, but we understand that it is a desired feature." --------------------------------------------------------------------------- Thanks Josh and partners in crime. I am pretty confident you will find a fix. Sorry for the pressure we put on you but that's part of "feedback", right? Thanks A LOT for everything that works GREAT, thanks to you all!

I'm another user of CulturedCode's Things and I want to add another STRONG vote for coming up with something to get this to work again. Thank you.

A very simple workaround for Thing's users is to drag and drop the url onto Things' icon (which, I'm sure, stands proudly in your Dock!). All the best, JPH

Another vote for adding support for Things autofill back in. This capability is what brought me back to FireFox from Chrome. If the FF team assumes the we will be happy with the "workaround" that JPH suggests above, it's back to Chrome for me. One of the reasons I use Things is that it makes capturing to-dos trivial. Yes, dragging the URL works, but it is nowhere near as trivial or quick as capturing it automatically when creating a new to-do. Please reinstate support for this feature.

What were the technical issues for removing cURL? Given the number of applications this change has broken, I am surprised that it is not being treated as a high priority. Is there an update yet?

For what it's worth (and it's not ideal), you can at least get the current URL with the following: tell application "Firefox" activate tell application "System Events" keystroke "l" using {command down} keystroke "c" using {command down} get the clipboard end tell end tell

Mozilla, any updates on this now 9 month old issue?

Yes, would love an update here. My current plan is to move to Safari as my one and only browser. That'd be a sad outcome. --Jimmy Wales, founder, Wikipedia.org

If somebody could answer comment 5 and ideally write a small spec for the syntax we should support, that would help a lot. I'm not sure what Josh's priorities are with respect to this bug but I suspect that fixing up out-of-process plugins for Firefox 4 is more important at the moment. Maybe Josh can comment here next week when he returns from his vacation. In any case, I think this bug should block Firefox 4 because it's a painful regression from Firefox 3.5. (In reply to comment #3) > Can I get an answer to comment #2? Important to know in order to determine > whether or not we can block on this. I agree with Jesse that it's very much > wanted, but without knowing if it's doable to expose only at the browser level, > can't block. > > Please renominate if we get new information here. I'm not sure what information is needed. Anything is fixable, we just need somebody to sit down and figure it out. Answering comment 2 is a part of that.

Tom, maybe you have some time for looking into this?

This patch demonstrates the feasibility of adding (completely contrived) AppleScript support into Gecko.

(In reply to comment #25) > Tom, maybe you have some time for looking into this? I might. Is the goal to just include support for the "Standard Suite" and "Safari Suite" initially? My "feasibility patch" shows that adding an sdef file and wiring into toolkit is pretty straightforward. Cocoa Scripting uses key-value coding pretty extensively. The real challenge may be delegating attributes to browser-specific code. (My thought is that, in any objects where that is necessary, those objects will keep a dictionary pointing to the delegates. The KVC methods such as setValue:forKey: and valueForKey: can then be forwarded to the correct objects.) The implementation would create a set of Objective-C classes for scripting purposes. These objects would call into Gecko to retrieve any necessary information.

Just saving away my current progress. I thought I would have time to work on this, but no longer do have the time.

Someone should be able to pick up this work pretty easily. For each AppleScript class, you will need to create a proxy class in Objective-C that will respond appropriately using Key Value Coding (KVC). The proxy objects (e.g., my CocoaScriptingXULWindow) have a pointer to the right XPCOM interface and essentially drill down into the DOM to obtain answers. So for windows, the patch basically converts from nsIXULWindow to NSWindow and then forwards the appropriate method calls. For documents and tabs, the patch will need to find the |tabs| elements under the |tabbrowser| and extract the correct information. (Dealing with all the DOM calls in Obj-C as opposed to JavaScript qualifies as "fun.") The real annoying part is writing the Objective-C |objectSpecifier| method for the proxy objects to return the correct "path" to the proxy so the AppleScript support can later reconstruct the chain of proxy objects. As it stands now, for window objects, I pass in the index so the proxy knows what index it has to return in its implementation of objectSpecifier. Another point is that the Firefox-specific code may need to live in the browser/ directory tree. The application delegate may need a way to instantiate document objects without hardcoding the class. Objective-C makes this easy since you can easily have a register method on the application delegate that takes an Obj-C Class type. I updated the sdef file to contain a "Firefox Suite" that is similar to the "Safari Suite" (although it is commented out). I apologize if the foregoing is incoherent. More of a brain dump!

Thanks Tom! Any start and/or thoughts on solving this are appreciated.

I wanna use RescueTime, so I will dust off my AppleScript

Any updates?

Google Chrome apparently has AppleScript support in recent versions. Design document is at: http://sites.google.com/a/chromium.org/dev/developers/design-documents/applescript

We are planning to support Applescript. The design document and current status can be found here: https://wiki.mozilla.org/Mac:AppleScript

Re-assigning this specific bug to nobody, work on this problem is being done in bug 608049.

No assignee, updating the status.