Open
Bug 516502
Opened 15 years ago
Updated 9 months ago
Re-add AppleScript support for getting the current URL
Categories
(Firefox :: Shell Integration, defect, P5)
Tracking
()
NEW
People
(Reporter: jruderman, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
24.82 KB,
patch
|
Details | Diff | Splinter Review |
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?
Comment 1•15 years ago
|
||
Is this what would fix the "Add URL from Minefield" in AddressBook?
Comment 2•15 years ago
|
||
Josh: how could we publish this as part of the Firefox app, then?
Comment 3•15 years ago
|
||
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+
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.
Updated•15 years ago
|
Assignee: nobody → joelr
Comment 7•15 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•15 years ago
|
Assignee: joelr → joshmoz
Comment 8•15 years ago
|
||
Josh, I'm busy with a static build but do assign this back if you feel you must.
Comment 9•15 years ago
|
||
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•15 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•15 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•15 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•15 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•15 years ago
|
||
This also broke my app, please fix ASAP!!
Comment 15•15 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•15 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•15 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•15 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•15 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•15 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•15 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•14 years ago
|
||
Mozilla, any updates on this now 9 month old issue?
Comment 23•14 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
Comment 24•14 years ago
|
||
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: --- → ?
Comment 25•14 years ago
|
||
Tom, maybe you have some time for looking into this?
Comment 26•14 years ago
|
||
This patch demonstrates the feasibility of adding (completely contrived) AppleScript support into Gecko.
Comment 27•14 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•14 years ago
|
||
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•14 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!
Updated•14 years ago
|
blocking2.0: ? → -
Comment 30•14 years ago
|
||
Thanks Tom! Any start and/or thoughts on solving this are appreciated.
Assignee: joshmoz → nobody
Hardware: x86 → All
Comment 31•14 years ago
|
||
I wanna use RescueTime, so I will dust off my AppleScript
Assignee: nobody → sayrer
blocking2.0: - → ---
Comment 32•14 years ago
|
||
Any updates?
Comment 33•14 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
Comment 34•14 years ago
|
||
We are planning to support Applescript. The design document and current status can be found here: https://wiki.mozilla.org/Mac:AppleScript
Updated•14 years ago
|
Status: NEW → ASSIGNED
Comment 36•14 years ago
|
||
Re-assigning this specific bug to nobody, work on this problem is being done in bug 608049.
Assignee: sgreenlay → nobody
Updated•5 years ago
|
Priority: -- → P5
Updated•2 years ago
|
Severity: normal → S3
Comment 39•2 years ago
|
||
The severity field for this bug is relatively low, S3. However, the bug has 61 votes.
:Amir, could you consider increasing the bug severity?
For more information, please visit auto_nag documentation.
Flags: needinfo?(ahabibi)
Comment 40•2 years ago
|
||
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?(ahabibi)
Comment 41•9 months ago
|
||
There is still a need for this. Refer to https://stackoverflow.com/questions/5296995/macosx-or-applescript-get-current-url-from-firefox
You need to log in
before you can comment on or make changes to this bug.
Description
•