Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
On Feb 20, 2012, at 9:29 PM, Mark Munz wrote: It was later determined that there is no intention of every allowing any kind of access to usability APIs from a sandboxed app. So they were apparently to afraid to just come out and say it, but instead used internal tracking option for the same effect. I believe the current sandbox documentation expressly states that assistive applications will not work in the sandbox. This means that software intended to help users with disabilities must not be sandboxed and cannot be distributed in the Mac App Store. And of course, the same applies to any utility applications that use the accessibility APIs for similar purposes, such as my own UI Browser and UI Actions products, as well as any applications based on Apple's own GUI Scripting AppleScript technology. Ditto for applications that send any AppleScript commands to other applications. I suspect that Apple's recent announcements regarding Gatekeeper were in part dictated by Federal regulatory requirements regarding the Americans With Disabilities Act, which prohibits the federal government, as well as many state educational institutions that rely on federal money, from buying computers that do not comply with the ADA. Developers of assistive software and utilities relying on the accessibility API or AppleScript to control other applications must advise their customers running Mountain Lion to select the Gatekeeper option to run applications with developer IDs as well as applications purchased through the Mac App Store -- fortunately, that is the default setting. These restrictions do not apply to applications that only respond to incoming accessibility API notifications or AppleScript commands. The documentation expressly encourages developers to continue to make their applications AppleScriptable, and of course the built-in and custom accessibility API support will continue to be available in the Cocoa frameworks and functional in sandboxed applications and in Mac App Store applications. -- Bill Cheeseman - b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
Don't hold your breath for a new API. Apple does not want sandboxed apps to communicate with each other except through extremely limited means: OS X Services (which is limited to static Services only) and what appears to be a one-way mechanism defined under Mtn Lion (not sure what part of it is under NDA and what part was covered in news articles). An Apple engineer claims the above is not true, but when I asked for a clarification on exactly how sandboxed apps were to communicate with other apps, I never got a response. This appears to not be just some blip, but is intentional and unlikely to change. I also filed bugs against this issue, which were closed and dubiously moved to internal tracking after months of no response. It was later determined that there is no intention of every allowing any kind of access to usability APIs from a sandboxed app. So they were apparently to afraid to just come out and say it, but instead used internal tracking option for the same effect. Mark On Fri, Feb 17, 2012 at 10:30 AM, Patrick Robertson robertson.patr...@gmail.com wrote: I've also filed a bug at least 3 months ago, and it appears Apple have been ignoring it. I have come to the same conclusion as you on the matter Nick. It seems we must either wait for a new API (which I think is unlikely to happen) or have to remove features that rely on this from our applications. Thanks for your reply Nick, it's nice to know that I'm not the only one. On 17 February 2012 18:27, Nick Zitzmann n...@chronosnet.com wrote: On Feb 16, 2012, at 1:22 AM, Patrick Robertson wrote: As a follow up, it appears that in 10.7.3 Apple have included a further Console log message along the lines of: 16/02/2012 08:12:28.319 sandboxd: ([23644]) WebProcess(23644) deny hid-control It appears that Sandboxed applications do not allow external applications to run the AXUIElementPostKeyboardEvent anymore. Do people consider this to be reasonable/make sense? Somehow, I don't see how it's justifiable for a Sandboxed app to display this behaviour, and causes serious usability problems. I have a bug filed on this, but I don't think Apple's ever going to allow use of the accessibility API or event posting from the sandbox. According to what I've read on the forums, allowing apps to do that is a sandbox-defeating security hole. Sandboxed apps aren't allowed to use NSAppleScript or AESend() to communicate with the outside world for the same reason. They get temporary exceptions, but the temporary means they might be taken away... Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/unmarked%40gmail.com This email sent to unmar...@gmail.com -- Mark Munz unmarked software http://www.unmarked.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
As a follow up, it appears that in 10.7.3 Apple have included a further Console log message along the lines of: 16/02/2012 08:12:28.319 sandboxd: ([23644]) WebProcess(23644) deny hid-control It appears that Sandboxed applications do not allow external applications to run the AXUIElementPostKeyboardEvent anymore. Do people consider this to be reasonable/make sense? Somehow, I don't see how it's justifiable for a Sandboxed app to display this behaviour, and causes serious usability problems. On 24 November 2011 10:25, Bill Cheeseman wjcheese...@gmail.com wrote: On Nov 23, 2011, at 4:40 PM, Patrick Robertson wrote: Did you ever get anywhere with this? Have you managed to confirm the bug? I still believe it's an OS X Lion bug, so it'd be good to be sure. I'm scheduled to start my annual review and upgrade of UI Browser in January. It's on my list to explore then. -- Bill Cheeseman - b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
On Feb 16, 2012, at 1:22 AM, Patrick Robertson wrote: As a follow up, it appears that in 10.7.3 Apple have included a further Console log message along the lines of: 16/02/2012 08:12:28.319 sandboxd: ([23644]) WebProcess(23644) deny hid-control It appears that Sandboxed applications do not allow external applications to run the AXUIElementPostKeyboardEvent anymore. Do people consider this to be reasonable/make sense? Somehow, I don't see how it's justifiable for a Sandboxed app to display this behaviour, and causes serious usability problems. I have a bug filed on this, but I don't think Apple's ever going to allow use of the accessibility API or event posting from the sandbox. According to what I've read on the forums, allowing apps to do that is a sandbox-defeating security hole. Sandboxed apps aren't allowed to use NSAppleScript or AESend() to communicate with the outside world for the same reason. They get temporary exceptions, but the temporary means they might be taken away... Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
I've also filed a bug at least 3 months ago, and it appears Apple have been ignoring it. I have come to the same conclusion as you on the matter Nick. It seems we must either wait for a new API (which I think is unlikely to happen) or have to remove features that rely on this from our applications. Thanks for your reply Nick, it's nice to know that I'm not the only one. On 17 February 2012 18:27, Nick Zitzmann n...@chronosnet.com wrote: On Feb 16, 2012, at 1:22 AM, Patrick Robertson wrote: As a follow up, it appears that in 10.7.3 Apple have included a further Console log message along the lines of: 16/02/2012 08:12:28.319 sandboxd: ([23644]) WebProcess(23644) deny hid-control It appears that Sandboxed applications do not allow external applications to run the AXUIElementPostKeyboardEvent anymore. Do people consider this to be reasonable/make sense? Somehow, I don't see how it's justifiable for a Sandboxed app to display this behaviour, and causes serious usability problems. I have a bug filed on this, but I don't think Apple's ever going to allow use of the accessibility API or event posting from the sandbox. According to what I've read on the forums, allowing apps to do that is a sandbox-defeating security hole. Sandboxed apps aren't allowed to use NSAppleScript or AESend() to communicate with the outside world for the same reason. They get temporary exceptions, but the temporary means they might be taken away... Nick Zitzmann http://www.chronosnet.com/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
On Nov 16, 2011, at 1:51 PM, Patrick Robertson wrote: AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, true ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, false ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command In the last step you should have passed false instead of true, to let the command key up. -- Bill Cheeseman - b...@cheeseman.name ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
AXUIElementPostKeyboardEvent - not sending key presses to Safari/TextEdit in Lion
Hi all, I've upgraded to Lion, and my app which sends simulated keyboard presses to various apps to activate a service cannot send these keyboard presses to Safari or TextEdit. The keyboard presses are still sent correctly to Xcode, Finder and Mail. I have also confirmed that they still work fine for Safari and TextEdit on Snow Leopard. Has anybody else come across this problem? Below is a snippet of my code, and attached [1] is a test app I made that sends ⌘N to various apps. Please not that a) the attached code was thrown together in a few minutes, and is not very elegant b) I cannot use CGEventCreateKeyboardEvent as I need to send the keyboard presses to an app other than the front app pid_t pid = **some pid, verified to be right** AXUIElementRef app = AXUIElementCreateApplication (pid); // Simulating a CMD ESC keypress AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, true ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)53, false ); //Escape AXUIElementPostKeyboardEvent (app, (CGCharCode) 0, (CGKeyCode)55, true ); //Command CFRelease( app ); [1] http://dl.dropbox.com/u/34827/KeyboardPress.zip ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
