airsdk / Adobe-Runtime-Support

Report, track and discuss issues in Adobe AIR. Monitored by Adobe - and HARMAN - and maintained by the AIR community.
197 stars 11 forks source link

StageText triggering Emojis & Symbols window on Mac OS Monterey #1323

Open perholmes opened 2 years ago

perholmes commented 2 years ago

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:

Screen Shot 2021-11-03 at 12 21 51

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:

Screen Shot 2021-11-03 at 12 22 08

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.

MalacTheLittle commented 2 years ago

I had same issue few days ago using TextField and solved problem with newer SDK (33.1.1.633.)

perholmes commented 2 years ago

Dynamite, thanks for the input, good enough reason to increase the SDK version.

ajwfrost commented 2 years ago

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

perholmes commented 2 years ago

Beautiful, thanks for the great support.

twistedmedia commented 2 years ago

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.

perholmes commented 2 years ago

Excellent tip, will tell our users until we're able to get a new release out.

wdankier commented 2 years ago

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?

MalacTheLittle commented 2 years ago

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.

wdankier commented 2 years ago

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!

ajwfrost commented 2 years ago

@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..

ybondarenko1986 commented 2 years ago

We experienced the same issue. Does anyone know when the new version of AIR Runtime 33.1.1.633 will be released?

ajwfrost commented 2 years ago

@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..?

twistedmedia commented 2 years ago

It still happens in ADL using .633 and Monterey 12.0.1.

-d.

Derek Frederickson | Playback Graphics Supervisor

Twisted Media Inc. | http://www.twistedmedia.com (773) 972-2972 | @.*** Atlanta • Chicago • Los Angeles

On Nov 12, 2021, at 10:33 AM, Andrew Frost @.***> wrote:

 @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..?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

blan-man commented 2 years ago

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.

perholmes commented 2 years ago

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.

blan-man commented 2 years ago

Only version 33.1.1.533 is available for download on the web site.

perholmes commented 2 years ago

That doesn't add up. We're building from 33.1.1.686.

blan-man commented 2 years ago

I'm talking about the runtime and not the SDK.

perholmes commented 2 years ago

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.

blan-man commented 2 years ago

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.

ajwfrost commented 2 years ago

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

blan-man commented 2 years ago

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.

wdankier commented 2 years ago

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...

ipnet-me commented 2 years ago

Hello, I found similar issue with char 'D' - Mac OS open Dictation windows

marcelmah commented 2 years ago

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?

NicolasDionB commented 2 years ago

I've tested with the latest SDK 33.1.1.731 and the problem is still present. Any update on this?

ajwfrost commented 2 years ago

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

NicolasDionB commented 2 years ago

@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. 🙄

ajwfrost commented 2 years ago

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

rogerclarkmelbourne commented 2 years ago

@twistedmedia

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

stoff99 commented 2 years ago

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: Tastatur_und_StageText_triggering_Emojis___Symbols_window_on_Mac_OS_Monterey_·_Issue__1323_·_airsdk_Adobe-Runtime-Support