Quicklooking a Script Filter item can prevent another Script Filter from firing

[vitor 895]

This is a weird bug, and hard to distil to one sentence (title). I’ve prepared a simple test case.

The Workflow is straightforward: it has one Script Filter with a single item—an argument to https://example.com. On actioning, it connects to an Arg and Vars utility which assigns {query} to a new url variable. Finally, that goes to another Script Filter, whose sole job is to show the value of url.

Now try to run it:

1. Call sctest (the first Script Filter).
2. Press ↵.
3. You’ll see it succeeds, showing the new Received Link Script Filter.

Now let’s change just one thing:

1. Call sctest (the first Script Filter).
2. Press ⇧ or ⌘Y to quicklook the URL.
3. Close Quicklook.
4. Press ↵.
5. It fails. The Workflow stops running.

Alfred 4.0.9 [1144]
macOS 10.14.6 (18G4032)

Edited May 11, 2020 by vitor
Changed host for the link

[Andrew 827]

@vitor uhhh that link wanted me to install Flash...

[Andrew 827]

But thinking about it, I guess you may have forgotten to select the following option in the connection, and the focus fettling of QuickLook is enough to throw Alfred into hiding after the first Script Filter is run.

 

:

 

 

[deanishe 1,449]

36 minutes ago, Andrew said:

that link wanted me to install Flash...

 

Probably some adtech crap. You don't need Flash to download the workflow.

 

32 minutes ago, Andrew said:

I guess you may have forgotten to select the following option in the connection, and the focus fettling of QuickLook is enough to throw Alfred into hiding after the first Script Filter is run.

 

That does fix the issue, but Alfred isn't just hiding. It isn't running the second Script Filter at all.

[Andrew 827]

@deanishe Alfred is attempting to show the second filter, but focus is being pulled (similar to you cancelling the script filter by clicking outside the window).

 

If you leave that connection option to the default of close Alfred (so you see the circle on the connection), and place a Delay object after the Arg/Var of e.g. 0.2 seconds, it will also give time for focus to sort itself out and the second Script Filter will run.

 

Essentially, this option in the connection exists for this very reason.

[deanishe 1,449]

13 minutes ago, Andrew said:

it will also give time for focus to sort itself out and the second Script Filter will run

 

Okay. I guess it's some implementation detail we aren't privy to.

[vitor 895]

4 hours ago, Andrew said:

uhhh that link wanted me to install Flash...

 

Apologies! I’ve replaced it. It’s been a while since I’ve used that host and I wasn’t aware they were now doing shady stuff. I frequently use two other temporary hosts that don’t pull crap like that, but they weren’t working at the time.

 

I can also confirm ticking the window behaviour box fixes the issue, but this does look like a bug somewhere (i.e. I’m not surprised if it’s on macOS), because after closing Quicklook I can wait a long time (I’ve gone over 10 seconds) with Alfred’s window open and it still doesn’t continue to the other Script Filter. So it’s a bit weird that adding the delay after the Arg and Vars works.

 

Even clicking the window before actioning doesn’t work. Which got me thinking: I’ve changed Alfred’s Focusing from Standard Mode to Compatibility and it works every time in that case. So I’ll file this under a bug with however macOS deals with focus on non-activating panels.

 

I’m going with the proposed solution of not letting Alfred close after actioning a result.

 

Thank you. This can be moved to resolved.

[Andrew 827]

3 hours ago, vitor said:

I’m going with the proposed solution of not letting Alfred close after actioning a result.

 

Alfred will do this under certain circumstances, for example, if you wire the script filter directly into another script filter, Alfred will KNOW that the window shouldn't be closed, but with another object in between, Alfred can't assume that you want to keep the window open.

 

I've gone in depth into this in the past, and can't find the conversation about it, but essentially the "don't close Alfred window" is exactly for the use case of needing Alfred's window to stay open when you need to wire from a script filter via other things to another script filter.

 

It boils down to a timing issue, as if you don't select the option to keep Alfred's window open, Alfred is requesting macOS to close Alfred, then just so happens to _catch_ it just in time to show Alfred again for the next script filter (sometimes with a flicker). When using QuickLook, it looks like macOS is doing something weird and changes the timing so unfortunately this lucky _catch_ doesn't work.

 

By selecting the option to keep Alfred open, Alfred doesn't ask macOS to close the Alfred window after actioning the result.

 

Does this make sense?

[vitor 895]

2 minutes ago, Andrew said:

It boils down to a timing issue (…) Alfred is requesting macOS to close Alfred, then just so happens to _catch_ it just in time to show Alfred again for the next script filter (sometimes with a flicker).

 

I see, so it was my assumption that was backwards. I should’ve found it strange when the window didn’t close, but Alfred was being smart enough to correct the behaviour in the cases I didn’t use Quicklook.

 

5 minutes ago, Andrew said:

Does this make sense?

 

Sure does! Thank you for the explanation.

[deanishe 1,449]

Interesting. I was surprised I hadn't run into this behaviour because quite a few of my workflows support Quicklook and chain Script Filters together indirectly.

 

But it seems I've always been careful to check "Don't close Alfred" because Niki gripes about the flicker when I don't.