StageText triggering Emojis & Symbols window on Mac OS Monterey
Opened this issue · 31 comments
Typing the E and D keys into our AIR app on Mac OS Monterey causes the Emojis & Symbols or the Dictation window to pop up instead of typing. This post is just an attempt at finding out if we're the only ones with the problem, or if anyone knows of mitigations.
The controls in our app use StageText. When an E is typed into text, the Emojis & Symbols window appears:
It seems that StageText is submitting all characters as though the Fn key is being held down. While you type E, the edit menu blinks, where this Emojis & Symbols feature is being added by Apple:
We've discovered that actually pressing the Fn key inverts this state, allowing you to type E and D (lowercase versions). And there's no problem typing uppercase versions, so Shift+E and Shift+D are fine.
We're on AIR SDK 33.1.1.44, and Flex 4.16.1. I'm happy to update everything, but I'd love to hear from anyone whether this is known and addressed in newer versions, since there's always some risk in updating.
I had same issue few days ago using TextField and solved problem with newer SDK (33.1.1.633.)
Dynamite, thanks for the input, good enough reason to increase the SDK version.
Just to confirm the change in 33.1.1.633:
AIR-5060: Prevent Function accelerators triggering with normal keypresses on Monterey
The problem was happening because AIR doesn't know about the "Function" key, so it was seeing the accelerator as being just "E" and "D" (on older macOS versions, the shortcuts for dictation/emojis were using the command key I think). As the first step we've basically just disabled Function accelerators so any keyboard shortcut that needs the Fn key will not work ...
The next step is to properly support the Function key as a separate keycode like we have for Control, Command etc, at which point we can add back the shortcut support.
thanks
Beautiful, thanks for the great support.
Same here, but can be solved on the system level by going to System Preferences -> Keyboard -> Shortcuts Tab -> Click Add (+). On the panel that pops up, set the Application drop down to All Applications. Menu Title: Emoji & Symbols. Keyboard Shortcut: Command Option e (or whatever you like). BOOM! Done.
Excellent tip, will tell our users until we're able to get a new release out.
I had the same problem.
When running our app from my IDE with SDK version 33.1.1.633, it solves the problem.
But when I run the .633 compiled app (.air) using the Air runtime environment, I stil have that same problem.
For now, I tested the workaround with the Keyboard Shortcuts so we can help our application's users, but I am stil not sure why I have this problem.
When I run from the IDE, it makes a difference when I compile with the .633 or a previous version.
When the app is compiled with .633 and run with the AIR runtime instead of the IDE, the problem persists.
What am I missing?
I believe it's up to AIR Runtime version you have installed on your system. Latest runtime available from Harman site is 33.1.1.533 so Harman should provide newer version of runtime.
Thanks for aal the support. It helped a lot! Thanks @MalacTheLittle, I believe the same. Let's wait for it. The Keyboard Shortcut should help for now. Thanks for that @twistedmedia!
@MalacTheLittle good point re the shared runtime version. We can look at issuing an update to that for macOS to get this working on shared versions too..
We experienced the same issue.
Does anyone know when the new version of AIR Runtime 33.1.1.633 will be released?
@ybondarenko1986 the updated shared runtime should be out next week.. if you have the SDK and run using build .633, you shouldn't see this issue any more..?
Any update on when the new version of AIR Runtime 33.1.1.633 will be released? Having this problem and the work around is not working for me as the dictation window is still popping up.
Any update on when the new version of AIR Runtime 33.1.1.633 will be released?
Isn't that already out? The problem is resolved in the latest SDK we're building from.
Only version 33.1.1.533 is available for download on the web site.
That doesn't add up. We're building from 33.1.1.686.
I'm talking about the runtime and not the SDK.
I wasn't aware the runtime was behind. But I should give the standard speech about building with a captive runtime instead. We've had a successful AIR app for about 8 years, and for some of those years, we released it with a separate runtime. It's asking for trouble in a lot of ways, including user confusion, alternative AIR versions already installed, and being seen as malware by the OS and antivirus software.
Thanks for the suggestion. We too have had an app for about 8 years. We are still distributing a separate app from the runtime. We may need to move in that direction.
Sorry - the updated runtime is created but isn't available on the webserver yet.. uploading it here for macOS:
AdobeAIR.dmg.zip
Will push the guys to get this update onto the public website asap...
thanks
Sorry - the updated runtime is created but isn't available on the webserver yet.. uploading it here for macOS: AdobeAIR.dmg.zip Will push the guys to get this update onto the public website asap...
thanks
Thank you - that fixed my issue. Currently we have a few customers on Mac, and none so far are using Monterey. Thanks.
How long does it take for the 33.1.1.633+ version to show up on the Runtime Download page? We just provide a link to this page...
Hello, I found similar issue with char 'D' - Mac OS open Dictation windows
Sorry - the updated runtime is created but isn't available on the webserver yet.. uploading it here for macOS: AdobeAIR.dmg.zip Will push the guys to get this update onto the public website asap...
thanks
Any news on when this (or newer) will be on the public website?
I've tested with the latest SDK 33.1.1.731 and the problem is still present. Any update on this?
Can I check how you're running the application? And are you able to put a (read-only) text field onto the stage alongside your input text field, with the text value set to flash.system.Capabilities.version?
thanks
@ajwfrost The version reports as 33.1.1.698 tough I really downloaded and compiled using the version 33.1.1.713 (sorry for the typo, not 731).
Also, quick update: it is fixed with the latest version. My coworker had a cache problem and was actually running my previous build with an older SDK. Sorry for all that. 🙄
Okay thanks - so yes, version 33.1.1.713 was just a bunch of changes in the packager, rather than the actual runtime binaries which are still therefore reporting 33.1.1.698.
But actually the issue should have been fixed with 33.1.1.633:
AIR-5060: Prevent Function accelerators triggering with normal keypresses on Monterey
So I'm hoping that the fix that went in there is actually sufficient! If it's working with the latest build though, that is good :-)
thanks
Is there a way to prevent the 'd' key triggering the dictation system.
I've tried assiging the Command D , Keyboard control panel -> Shortcuts, but it has no effect.
I also tried changing the shortcut key in the Dictation tab in the Keyboard control panel, but again, it has no effect
It looks almost like Command D is hard coded somewhere in MacOS, and that key combination can't be reassigned
BTW.
Deploying an updated version is not an option for me at the moment because of other problems
Hey @rogerclarkmelbourne,
the workaround with Command D , Keyboard control panel -> Shortcuts is working.
The main problem is that its system language related. You have to type the menu title as string and not an id or something.
So if you are using german you have to write "Emoji & Symbole" and when you use english "Emoji & Symbols".
I had the same issue right now with our Flex application which i cannot simply update to a new air version ...
I made the shortcut override with alt + cmd + d and alt + cmd + e.
Here is a screenshot:
