[How To] Get frontmost tab’s url and title of various browsers

[txaidw]

Thanks Vitor, the problem was I was using "of front document" instead of "of front window"

[deanishe]

This Workflow not work with Alfred3

 

 

This thread isn't about a workflow…

[vitor]

Updated the top post (and the gist) with the JavaScript for Automation (JXA) equivalent. It is superior to the AppleScript code in a number of ways (explained in the comments).

[cdpath]

Any update for Firefox? I use Vimperator and send key strokes to get the title and url, but it's not reliable...

[vitor]

7 hours ago, cdpath said:

Any update for Firefox? I use Vimperator and send key strokes to get the title and url, but it's not reliable...

 

You’re asking in the wrong place — there’s nothing I can do about it. Ask in their bug tracker.

[skeskali]

Is there a way to update this to include Vivaldi?

[deanishe]

22 minutes ago, skeskali said:

Is there a way to update this to include Vivaldi?

 

As a courtesy, you might have posted a link to the browser.

 

To answer your question, the scripts for Chrome/Chromium work with Vivaldi. You just need to change the application name.

[skeskali]

Thanks, deanishe!

[vitor]

Updated scripts to add Vivaldi.

[derBingle]

Not too long ago I switched to using Opera as my everyday browser. I really like it (Chromium + native ad blocking + better looking), but missed all the Alfred workflows that get the current URL. 

 

I've already been doing some GUI scripting for other reasons, so the last time by muscle memory I tried to use a "current url" workflow in Opera, I decided to see how hard it would be. Turns out, not hard at all—here's what I added to the script to make it work for Opera: 

 

else if (frontApp = "Opera") then
  tell application "System Events"
	tell application process "Opera"
	  set currentTabUrl to value of text field "Address field" of toolbar 1 of (first window whose subrole is "AXStandardWindow")
	end tell
  end tell

Note: The whole url needs to be showing in the address bar, since that's where this gets it from. So make sure Settings > Browser > "Show full URL in combined search and address bar" is checked. Otherwise, for example, "https://www.google.com/" would just return "www.google.com". Also, Alfred needs to have Accessibility access, but if you're reading this, it most likely already does. ?

 

Hope it helps someone!

Edited September 21, 2017 by derBingle
fix code indentation

[vitor]

@derBingle That method seems fine, but I won’t add it to the list because it’s a bit hackish. For it to be added to the gist, it needs to be part of the app’s AppleScript dictionary and have both URL and page title support.

[derBingle]

5 minutes ago, vitor said:

@derBingle That method seems fine, but I won’t add it to the list because it’s a bit hackish. For it to be added to the gist, it needs to be part of the app’s AppleScript dictionary and have both URL and page title support.

 

Understood. ?? I didn't figure you would add it to the gist—it's most definitely an (unavoidable) hack and also subject to change with any changes to Opera. Mainly just sharing for any other Opera switchers like me who want to get back the functionality in their workflows.

[skeskali]

On 8/20/2017 at 11:31 AM, vitor said:

Updated scripts to add Vivaldi.

Thanks, vitor!

[MacFreek]

The following Applescript works fine for me with Opera 51.0 on macOS 10.13.3. Perhaps support was added back in? (I have Accessibility enabled in System Preferences, not sure if that matters):

tell application "Opera" to return title of active tab of front window
tell application "Opera" to return URL of active tab of front window

 

[vitor]

You are correct, @MacFreek. And not only that, they finally show a dictionary. They’ve also changed from the Safari method to the Chrome method.

 

I’ve updated the top post and the gist. Thank you.

[vitor]

Added support for Brave.

[JGC]

This is useful as far as it goes ... but I want to take it further. Namely to automatically select the most recent tab of the most recently used browser.

So I spent some considerable time working out how to do this, and fixing other things in this that gave me errors, at least for my two installed browsers, Google Chrome and Safari.

You can follow some of the discussion and help on StackOverflow.  Here's the conclusion suitable for use in Alfred.

on alfred_script(q)

property nil : ""

set [currentTabTitle, currentTabUrl] to [nil, nil]

set cmd to "lsappinfo metainfo | grep -E -o 'Safari|Google Chrome' | head -1"
set frontmostBrowser to do shell script cmd

if the frontmostBrowser = "" then return nil

if the frontmostBrowser = "Google Chrome" then

    tell application "Google Chrome" to tell ¬
        (a reference to the front window) to tell ¬
        (a reference to its active tab)

        if not (it exists) then return nil
        set currentTabTitle to its title
        set currentTabUrl to its URL
    end tell

else if the frontmostBrowser = "Safari" then

    tell application "Safari" to tell ¬
        (a reference to the front document)

        if not (it exists) then return nil
        set currentTabTitle to its name
        set currentTabUrl to its URL
    end tell

end if

return "[" & currentTabTitle & "](" & currentTabUrl & ")"
end alfred_script

However, this doesn't work when embedded as an Alfred "RunNSAppleScript" workflow item, and I can't tell why. (I had it triggered by snippet '\\url' but of course there are other ways of doing this.)

 

[vitor]

1 hour ago, JGC said:

but I want to take it further. Namely to automatically select the most recent tab of the most recently used browser.

 

I’ll argue that’s not taking it further, it’s taking it in a different direction. The code was never trying to do what you suggest; its goal was always to grab the frontmost browser, not the most recently used. It even has a failure case for when no supported browser is up front, to respond accordingly. Your method can lead to unforeseen results.

But if it works for your needs, do it!

 

1 hour ago, JGC said:

this doesn't work when embedded as an Alfred "RunNSAppleScript" workflow item

 

Unless you know what you’re doing and that you need to use Run NSAppleScript, don’t. Use a Run Script with /usr/bin/osascript instead (the Run NSAppleScript points that out).

[luckman212]

On 4/5/2017 at 11:04 PM, cdpath said:

Any update for Firefox? I use Vimperator and send key strokes to get the title and url, but it's not reliable...

 

I tried to make the jump to Firefox last week (adblockalypse). I'm fundamentally opposed to supporting Google's omnipotence, but a few things caused me to give up (for now) and revert to Chrome. This lack of scriptability was one of the biggest ones. I have a bunch of scripts, workflows, and Automator services around browser windows. These depend on being able to reliably fetch the URL of the current browser tab. I commented on FF bug#125419 but so far no response. Nor am I hopeful that we'll see movement on this, seeing how the bug is old enough to fight & die for its country. But I will keep checking back from time to time. I hope to try the switch again later this year.

[GHPen]

On 6/7/2019 at 3:13 PM, luckman212 said:

 

I tried to make the jump to Firefox last week (adblockalypse). I'm fundamentally opposed to supporting Google's omnipotence, but a few things caused me to give up (for now) and revert to Chrome. This lack of scriptability was one of the biggest ones. I have a bunch of scripts, workflows, and Automator services around browser windows. These depend on being able to reliably fetch the URL of the current browser tab. I commented on FF bug#125419 but so far no response. Nor am I hopeful that we'll see movement on this, seeing how the bug is old enough to fight & die for its country. But I will keep checking back from time to time. I hope to try the switch again later this year.

 

If you only need the URL, you could simulate a ⌘+L and ⌘+C, right? The script in this blog post gets both the URL and the tab title.

[deanishe]

32 minutes ago, GHPen said:

If you only need the URL, you could simulate a ⌘+L and ⌘+C, right?

 

Yes, but as the author of the article you linked says:

 

Quote

any automated interaction with the application must be clumsily achieved through simulating GUI events. I found out that such GUI-based automation is prone to failure.

 

When you simulate keypresses, you're just blindly firing them at the application and hoping that it's in the right state to receive them as intended.

 

It is very much a last resort, and does not compare to actually being able to query the application's state.

[vitor]

Updated code for both versions to detect more variants and support Microsoft Edge.

[nikivi]

Here is solution for Firefox I came across. Maybe useful.

https://twitter.com/rsnous/status/1292136810169028609

[vitor]

On 8/8/2020 at 10:18 PM, nikivi said:

Here is solution for Firefox I came across. Maybe useful.

https://twitter.com/rsnous/status/1292136810169028609

 

It’s different but looks no better than the other finicky solutions. May be even worse, because it depends on the browser interface (which is unlikely to but may change). The code is also inefficient (there’s no point in setting a variable to return it right after) and still doesn’t solve the issue of getting the title of the page.

[deanishe]

8 hours ago, vitor said:

there’s no point in setting a variable to return it right after

It needs to set the variable because it turns accessibility off before returning it, doesn’t it?