For years I have used this code
tell application "System Events"
set arrURL to value of UI element 1 of combo box 1 of toolbar 2 of first group of front window of application process "Firefox"
end tell
to get the URL of the frontmost window in Firefox but recently it stopped working with the following error message:
System Events got an error: Can’t get combo box 1 of toolbar 2 of group 1 of window 1 of application process "Firefox". Invalid index.
Has something changed with Firefox?
Yes.
Here is the current way.
tell application "System Events"
set arrURL to value of text field 1 of combo box 1 of group 1 of toolbar 2 of group 1 of window 1 of application process "Firefox"
end tell
or a slightly simpler version…
tell application "System Events" to tell application process "Firefox"
set arrURL to value of combo box 1 of group 1 of toolbar "Navigation" of group 1 of window 1
end tell
Do you know why it changed? Will it be more scriptable?
I used
tell application "System Events"
set arrURL to value of text field 1 of combo box 1 of group 1 of toolbar 2 of first group of front window of application process "Firefox"
end tell
The code by @robertfern is the answer for the current version of Firefox.
But, regarding your follow-up questions:
UI scripting is inherently fragile. The developers of an app can rearrange UI elements for all kinds of reasons. That breaks code that is reliant on a hard-coded path to a specific object.
It seems doubtful that Firefox will ever be more scriptable. I think the “AppleScript Support” bug in its bug tracker has been around for over 20 years, and they may have finally closed it as “not gonna do that”.
But, you might be able to make the UI scripting workaround (a bit) less fragile by trying to remove some of the hard-coded references. There is an AppleScript UI scripting command, “entire contents of”, which returns all the nested UI elements of a UI element. That will often be way too much to run on a whole Firefox window, since that includes all the tabs and all the objects IN the web page of all the tabs (yikes!). But, if you start with the “toolbar 2 of first group of front window”, you still have some potentially breakable code, but less of it.
Two options, then. The first is to assume that if there is a “text field” in toolbar 2, that’s the address bar. The second is to worry that there might (eventually) be multiple text fields, but the one whose accessibility description contains the word “address” is the one you want. Firefox has almost zero AppleScript friendliness (long-standing bug they have declined to ever fix), but they do (loosely) support some accessibility features of macOS.
Here’s code for the first option (any text field in toolbar 2 must be the one we want):
tell application "System Events"
tell toolbar 2 of first group of front window of application process "Firefox"
set uiElems_List to entire contents as list
repeat with uiElem in uiElems_List
if class of uiElem is text field then
return value of uiElem
end if
end repeat
end tell
end tell
Here’s the second option (might be more than one text field in toolbar 2, so check for “address” in accessibility description):
tell application "System Events"
tell toolbar 2 of first group of front window of application process "Firefox"
set uiElems_List to entire contents as list
repeat with uiElem in uiElems_List
if class of uiElem is text field and accessibility description of uiElem contains "address" then
return value of uiElem
end if
end repeat
end tell
end tell
Well, it has worked for years and it is only me using the script so if I have to change it every few years it is not big deal.
However, in this specific case I think sending key events is at least as stable as using a native AppleScript solution: ⌘ L, ⌘ C.
Good points. And, you’re probably right that the keyboard shortcut method will be pretty stable. One potential downside is that it interferes with clipboard contents. It might be nice to save the clipboard before you run that copy, and restore original clipboard contents after you read the URL from the clipboard.