Keyboard becomes unusable after starting up workflows in Alfred 3.01 [Fixed 3.1 b708 pre-release]

[robhoenen]

After upgrading from 3.0 to 3.01 I can startup workflows but immediate the keyboard becomes totally unusable. It seems like the command or option or another function-key is stuck.  

I can replicate this problem immediate bij starting up any of my workflows. In version 3.0 I had no problem. In 3.01 this problem started. Screenshots can’t be provided since the keyboard is unresponsive and does totally unexpected things.

I’m using the newest Alfred version 3.01 and Mac OS X 10.11.5

When i don’t use Alfred workflows the keyboard is ok and there is no problem at all.

Anybody who can help me? I used my workflows for years and did’t experience any problem before with these same workflows…

 

THNX for helping 

 

[FroZen_X]

After upgrading from 3.0 to 3.01 I can startup workflows but immediate the keyboard becomes totally unusable. It seems like the command or option or another function-key is stuck.  

I can replicate this problem immediate bij starting up any of my workflows. In version 3.0 I had no problem. In 3.01 this problem started. Screenshots can’t be provided since the keyboard is unresponsive and does totally unexpected things.

I’m using the newest Alfred version 3.01 and Mac OS X 10.11.5

When i don’t use Alfred workflows the keyboard is ok and there is no problem at all.

Anybody who can help me? I used my workflows for years and did’t experience any problem before with these same workflows…

 

THNX for helping  

 

To let us see what is happening you can create a gif with this tool for instance: http://www.cockos.com/licecap/

Then upload it at http://imgur.com/

 

You can use the direct link and post it here by clicking the little image sign when posting → don't forget to remove the img stuff in brackets

 

Other than that, does the problem appear immediately when you start Alfred and type anything in it?

Could it be that you use the same hotkey for Alfred and spotlight?

Take a look into the Console.app if you see any crashes relating to Alfred. 

[robhoenen]

Hi there, thnx for helping me out
I spend several hours to create the gif you asked for. I didn’t succeed because when I start any Alfred workflow the keyboard starts getting its own life and it’s just impossible to work on… Sorry for that…

Without using any workflow I don’t have any problem using Alfred or my computer. I also don’t experience any other problems until I use Alfred  workflow. I don’t use the same hotkeys for spotlight and/or Alfred. Checked that multiple times.

This could be found in the console.


 

[Vero]

After upgrading from 3.0 to 3.01 I can startup workflows but immediate the keyboard becomes totally unusable. It seems like the command or option or another function-key is stuck.  

 

 

During that time, does the keyboard work in other apps and just not in Alfred or does it stop working globally on your Mac?

 

Alfred doesn't do anything at a low enough level to be able to crash your Mac, so if the keyboard becomes unusable, could you please launch Activity Monitor, choose Alfred 3 and click "Sample Process". Email us the results so that we can take a better look at what Alfred is up to during that time.

 

Cheers,

Vero

[robhoenen]

Hi Vero,

Thank you for helping me!
No, using a workflow will cause a global keyboard problem. It looks like the command key, the option key or the shift key is/are stuck. I can’t type any tekst because one of those function-keys seems to be pressed. FE pressing a “p” causes the command-p (print) option. This will happen in Word or Safari or…but only after using a Alfred workflow. There is the no other way to stop this strange behavior then a full reboot.
You can download the logs you asked for here and here. 

 

Greetz Rob.

[Vero]

Hi Vero,

Thank you for helping me!

No, using a workflow will cause a global keyboard problem. It looks like the command key, the option key or the shift key is/are stuck. I can’t type any tekst because one of those function-keys seems to be pressed. FE pressing a “p” causes the command-p (print) option. This will happen in Word or Safari or…but only after using a Alfred workflow. There is the no other way to stop this strange behavior then a full reboot.

You can download the logs you asked for here and here. 

 

Greetz Rob.

 

 

Hi Rob,

 

It sounds like there's one particular workflow that may be at the root of that issue; It may be that the workflow is getting stuck on a particular call.

 

Start by launching Alfred's preferences to the Workflows tab and right-click a workflow in the sidebar to allow you to disable them. You should be able to identify which workflow is responsible for the issue.

 

Cheers,

Vero

[robhoenen]

OK did that.

What is strange this behavior didn’t occur when working in Alfred 2 versions en Alfred 3.0 version…?!
This seems to be the troublemaker:

[FroZen_X]

OK did that.

What is strange this behavior didn’t occur when working in Alfred 2 versions en Alfred 3.0 version…?!

This seems to be the troublemaker:

 

Would be helpful if you could share the workflow that is making the trouble, so that one can check what's going on. Or you yourself know already what is messing up inside. It could be anything but most likely a reference to Alfred 2 or so that is still in there when its old.

[Vero]

OK did that.

What is strange this behavior didn’t occur when working in Alfred 2 versions en Alfred 3.0 version…?!

This seems to be the troublemaker:

 

 

Ok, so you're one step further forward now that you've been able to narrow it down to that workflow.

 

At this stage, you'll need to take a look at the following:

- Which hotkey within your workflow is the problem one?

- If you change the hotkey, does the issue stop? (The hotkey may be launching else on your Mac as you've selected some fairly basic/common hotkeys)

 

- What does this hotkey launch in Alfred? Could the app/file it's trying to launch be the issue?

 

It may take a little bit of deduction on your part, but this should help you on your way.

 

Cheers,

Vero

[robhoenen]

OK so I did the final deduction and disabled all workflows.
Then created a new simple workflow bij first defining a hotkey then an file-action opening an Excel file and finally connected the two to each other.

The result was the same, the keyboard got messed up as you can see here where it should say “qwerty”.

Here you can find my brand new test workflow.

I tested , retested with the same result. An insane keyboard after using an Alfred workflow where the only solution is rebooting. 

 

I really am out of options now I think?

There are now several options: My Mac is buggy, My OS X is buggy, Alfred 3.01 is….or last but not least….I’m buggy         

CU 

[Vero]

OK so I did the final deduction and disabled all workflows.

Then created a new simple workflow bij first defining a hotkey then an file-action opening an Excel file and finally connected the two to each other.

 

 

This is such a simple workflow, there's no way for it to do anything in itself other than launch the file you set to open.

 

- Do you have any key modifiers or third-party apps on your Mac that modify keyboard behaviour when alt is pressed?

- Do you have an odd key combination set to change your keyboard language (under System Preferences > Keyboard > Input Sources)?

- Are there any apps under System Prefs > Security & Privacy > Accessibility  that you don't expect to see there that would have control over your keyboard?

 

This isn't something we've encountered with anyone before, so it's difficult to provide any further suggestions. 

 

I would imagine that if you create a new user account on your Mac temporarily, you most likely won't encounter that same issue so it'll be something installed on your particular user profile.

 

Cheers,

Vero

[robhoenen]

Hi Vero,

After two days of deduction the problem seems to be solved   
There was a conflict between the Wacom tablet driver and something with Alfred. I updated the WACOM driver to the last version and then the problem vanished.

I was triggered for searching the WACOM driver because there was a entry in the console-log which I didn’t trusted.

Then I de-installed the WACOM-driver, downloaded the newest one an installed it. Until know…a day later…no problem.
I don’t know what was the exact problem, even don’t know 100% if the Wacom-driver was the problem but I’m happy for the moment!   

Thnx for helping me! Greetz Rob     

[rossbennett]

I began having this problem, too, when we received OS X 10.11.6 Beta 5.  I had no luck finding the cause of this for a while, so I rolled back to 10.11.6 Beta 4 and the problem was resolved.

 

But then this week, 10.11.6 final release came out and the problem returned.  Rather than roll back with TimeMachine I was able to spend some time isolating it. I believe I have.

 

The problem seems to be in the Hotkey module of the Workflows.  I have a few workflows which are keyed to Command-Option-<Letter>.  Whenever I'd trigger one, I would end up with a permanently-"pressed" Option key (which triggers extended characters in most Keyboard Input Methods).

 

On closer inspection, one sees that the workflow Hotkey settings include a setting on what to do with the modifier keys that are part of the trigger. All the workflows which were corrupting the keyboard state had this setting in their Hotkey:

[image disallowed]

 

However a "simulated modifier key release" is accomplished, it seems to not be working as well for the Option key as it is for the Command key. (At least as far as the operating system is concerned.) Until the next user login, the keyboard ˙ʼ--ø˜-¥ ˘´¨ß´ƒ¨-ƒø® þ¥,ʼ˜© ´.þ´˜ð´ð ¸ˍ¯®¯¸þ´®ß.

 

Workaround! But good news:  Just go into all the problematic workflows and change the Hotkey passthrough behavior to "Pass through modifier keys (Fastest)" and everyone will live happily and functionally-ever-after.

 

[image disallowed]

 

 

I don't know when this began in Alfred, because it only began happening to me in the very latest beta and final release of El Capitan. It also only happened on my Macbook Pro Retina 2015 (internal keyboard on the USB bus) and not on the Mac Mini at the office (bluetooth-connected keyboard).

 

It was happening with the macOS Sierra public beta 1 during the brief time I had it installed (only on the MBPr).

 

I isolated the behavior and confirmed the workaround on Alfred 3.0.3 [694].

 

ps.  I can't tell in the editor here whether the embedded images are going to display correctly.  Just in case, here's a link to the first one, and here's a link to the second one.

 

Hope this helps!

 

Ross

[robhoenen]

Thank you Ross,

Yesterday I updated to 3.0.3 and all the trouble started again. I thought I was the only one on this planet having this problem.

Previous I reinstalled Keepass 3.0.2 end recreated all workflows. That worked, no problems anymore.
Then, after the update, alle the strange keyboard-behavior was back again. I deleted the hotkey and assigned a input>keyword to the workflow. All the trouble was over. I think the update of Alfred, starting from 3.0.1 (3.0.0. did not have this problem) are the problem. 
At this moment I’m testing your workaround and it seems to work. I’ll test next days and hope this is the solution. 
 

It would be great if somebody could discover the cause of this “bug” appearing after each update since 3.0.1  

 

For now thanks very much         

Rob

[Andrew]

I'm going to have a bit more of a play with this today to see if I can reproduce the issue, and either way, see if there is anything I can do to improve the behaviour for you!

 

I'm going to move this back into the bugs forum for now

 

Cheers,

Andrew

[robhoenen]

Super, thnx Andrew ! 

[Andrew]

Could you both pop an email to our info@ address, I'd like to give you a beta build which should sort the issue.

 

Cheers,

Andrew

[rossbennett]

Surely!  It's on its way.  (He says for thread completeness.)  :-)

[robhoenen]

Me 2 , I’ll send it in a moment  

[pixelbrain]

I've been chasing this problem for several weeks as well. Keyboard problems, stuck Command and other keyboard responsiveness issues. Rebooting or logging out would temporarily fix. Problems solved when disabling Alfred.

Edited September 7, 2016 by pixelbrain

[rossbennett]

I've been feeling guilty this past couple of weeks because I haven't yet answered Andrew's latest email about this. [We got kind of overwhelmed at work, so the testing has been pretty slow.]

 

I've been testing the circumstances of this behavior with every keyboard-related utility I have—and that's a fair number.  (I own a print shop.) 

 

The findings to date:  No text replacement utilities, keyboard remapping utilities, or multilanguage/symbol keyboard input methods cause this problem.  Only one thing seems to be at issue:  Recent, if not only the most recent, versions of the Wacom Intuos drivers for OS X.  Specifically version 6.3.17-5 and perhaps a few others which were previously released and are no longer distributed on the Wacom support site.

 

One earlier version—6.3.17-5 is still distributed on the Wacom support site because it was the last version of the drivers to support the Intuos 3 tablets. It will also drive the latest Wacom Intuos line and it does not cause the problems described in this thread.

 

If you rely on the latest version of the Wacom drivers, the workaround described above will still work fine, but the problem still exists in the combination of the Wacom drivers and the newest release of Alfred.  (There have been two public releases of Alfred since I started testing these, and no releases so far of the Wacom driver set.)

[Andrew]

I've been testing the circumstances of this behavior with every keyboard-related utility I have—and that's a fair number.  (I own a print shop.) 

 

Can I ask if you exhibit this behaviour if you disable snippet expansion in Alfred?

 

Many thanks,

Andrew

 

[moving to investigating]

[rossbennett]

Good morning, Andrew!

 

Ooh!  I don't think I knew about this setting.  If you mean "Automatically expand snippets by keyword." (We use snippets to associate product catalog numbers with their descriptions, so we need the keyword left intact as often as expanded, e.g. "G240" is the keyword for "Gildan Ultra Cotton 6 oz. Long-Sleeve Tees")

 

What with the old MVC danger of never-initialized things, I went in and enabled the auto-expansion, tried it, disabled the auto-expansion, and tried it again.  Behavior was the same in each instance.  [Currently on 3.1 build 718.]

 

At this point I'm confident it's a problem in the handling in the Wacom drivers. They're trying to be clever with on-screen indicators of which modifier keys are pressed at any given time when the stylus or fingers are on the tablet.  

 

Their hardware has programmable keys, some of which default to Shift, Command, Option, and such.  But I've individually remapped the keys in the Wacom software so none of these modifier keys are assigned to their hardware.  Even when we do this, they seem to be grabbing the modifier status which I suspect is blocking your eminently reasonable release process.

 

I've spent quite a bit of time trying different settings in the Wacom configuration and none will change the behavior. It leads me to conclude they're installing some kind of status monitor their software can subscribe to if it's needed, and that's the offending component.  After all—these problems still happen when the Wacom hardware is disconnected and packed away in its dust cover.

[deanishe]

Try killing the Wacom software when you're not using the tablet. You might have to bugger about a bit with some Launch Agent settings to prevent the software from being restarted automatically.

 

You can also enable/disable the actual driver with sudo kextload -b <bundle id> / sudo kextunload -b <bundle id> respectively. I strongly suspect that it's not the actual driver, but rather some other POS Wacom program that's causing the issues.

 

Launch Control is a great app for editing Launch Agents.

Edited September 8, 2016 by deanishe