Re-add AppleScript support for getting the current URL

ASSIGNED
Unassigned

Status

()

Firefox
Shell Integration
ASSIGNED
8 years ago
2 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
All
Mac OS X
Points:
---
Bug Flags:
wanted-firefox3.6 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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
Flags: blocking-firefox3.6?
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.
Flags: blocking-firefox3.6? → wanted-firefox3.6+

Comment 4

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

Comment 5

8 years ago
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.

Comment 6

8 years ago
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.

Updated

8 years ago
Assignee: nobody → joelr

Comment 7

8 years ago
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.

Updated

8 years ago
Assignee: joelr → joshmoz
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.

Comment 10

8 years ago
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.

Comment 11

7 years ago
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

Comment 12

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

Comment 13

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

Comment 14

7 years ago
This also broke my app, please fix ASAP!!

Comment 15

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

Comment 16

7 years ago
"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!

Comment 17

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

Comment 18

7 years ago
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

Comment 19

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

Comment 20

7 years ago
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?

Comment 21

7 years ago
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

Comment 22

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

Comment 23

7 years ago
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.
blocking2.0: --- → ?
Tom, maybe you have some time for looking into this?

Comment 26

7 years ago
Created attachment 455904 [details] [diff] [review]
feasibility patch

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

Comment 27

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

Comment 28

7 years ago
Created attachment 456966 [details] [diff] [review]
work-in-progress v1

Just saving away my current progress.  I thought I would have time to work on this, but no longer do have the time.
Attachment #455904 - Attachment is obsolete: true

Comment 29

7 years ago
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!
blocking2.0: ? → -

Comment 30

7 years ago
Thanks Tom! Any start and/or thoughts on solving this are appreciated.
Assignee: joshmoz → nobody
Hardware: x86 → All

Comment 31

7 years ago
I wanna use RescueTime, so I will dust off my AppleScript
Assignee: nobody → sayrer
blocking2.0: - → ---

Comment 32

7 years ago
Any updates?

Updated

7 years ago
Assignee: sayrer → sgreenlay

Comment 33

7 years ago
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
Status: NEW → ASSIGNED
Depends on: 608049
Duplicate of this bug: 491005

Comment 36

7 years ago
Re-assigning this specific bug to nobody, work on this problem is being done in bug 608049.
Assignee: sgreenlay → nobody

Updated

2 years ago
Duplicate of this bug: 46407
You need to log in before you can comment on or make changes to this bug.