That wouldn’t explain why it succeeds on my system yet not on someone else’s. Besides, I don’t think it’s completely true: whilst the result is indeed a list of lists, if it has not been de-referenced yet, then filters can still be applied if you structure them carefully, e.g. using the word it where you might not otherwise need to, or by using a contains operator instead of an =. I’ll dig out an example later when I have time.
But I can see your logic applies very well to this particular case, though my confusion was more about why the OP and I were seeing different outcomes on identically set up systems. Still no answer to that peculiarity.
Following on from earlier, here's a simple example that allows a property of an object to be accessed on an individual basis within a whose filter, despite being inside a nested object list:
use application "System Events"
folders of folders of folders of folder "~/Example" whose name is "Nested"
Yes, you were able to get a result – similar to the result in Chrome with multiple windows open.
But...
Show me an effective way of now acting ON the entire result (without iterating through it).
Something similar to this (but working):
set targetFolder to path to downloads folder
tell application "System Events"
duplicate (folders of folders of folder "~/Example" whose name contains "second") to targetFolder
end tell
Here's an animated GIF (the forum wouldn't let me upload an .mp4 despite it being much smaller in file size) that demonstrates the closure of multiple tabs in multiple windows of Chrome by way of an AppleScript whose filter.
I'm curious to know which of mine or the OP's system is the odd one out ? Are you able to do this in Chrome, @ccstone ?
Yes, this fails on my system too. That's because the list will contain an empty list in it, which can't be acted upon by the close command.
So, it seems that closing multiple tabs in multiple Chrome windows works on your system with the URL property, so I'm willing to wager that it will also work with the name (title) property. And, given this, that makes the OP's system the odd one out.
But I don't believe in odd-one-outs, especially in computing. So, I'm wondering if it failed because there was another Chrome window open that didn't have a "Linguee" tab in it. Thanks, @ccstone, I think you may have solved this conundrum.
Most of this went over my head but that was the case during my testing. There was always at least one window open that did NOT have a Linguee tab in it. That was the issue then?
It appears so. It’s not really an issue, as that behaviour is perfectly explainable. It didn’t occur to me at the time, however. But, it’s a good thing you did have that extra window open. If you hadn’t, and you’d walked away with the initial one-liner AppleScript, then at some point in the real world, you’d have probably had a Chrome window open without any “Linguee” tabs open, and the script would fail to do its job, which would disrupt your work.
Thankfully, we were forced to take a more exhaustive approach to the problem, which works in all situations.