I have an NSSecureTextField field in my MacOS app. I want to disable the password autofill button from coming up (the "Passwords..." button). I've seen posts about doing it in iOS, but haven't seen anything on Mac OS. How can I do this? Thanks
It is possible to disable password autofill, due to the current default behaviour of showing the autofill button on the first NSSecureTextField in a window. But it is a kludge.
I find that if you create a dummy NSSecureTextField above the field of concern, and hide it behind another pre-existing field, you can avoid the autofill button appearing. I set this dummy field with NSTextContentTypeOneTimeCode.
Note this only works if the dummy NSSecureTextField is in the key view loop, so hiding it, or setting refusesFirstResponder doesn't help. This also means you need to handle the case where the end user is tabbing from field to field, so as to skip the dummy field.
The focus skipping can be achieved by detecting the completion of editing of the previous field (controlTextDidEndEditing:) and changing the focus if and only if the focus is on the dummy field.
All a bit complex for something that could be simply solved with an appropriate NSTextContentType!
Yes, Michael Rourke is right - using autofill in cocoa apps causes many problems. If for example I develop an app with a native register screen, user will see the autofill provider which propose existed passwords instead to offer a new one. It's only the one way to hide provider - oneTimeCode. But user could get an empty transparent pop-up (I really think we can find workarounds to hide it, eg use window.makeFirstResponder(textField)) and it's not the most big problem.
As for me the biggest problem is an inability to save new credentials to the icloud keychain and link it with your web domain (But I could be wrong:) ). It is strange to create a password in the application without the possibility of its subsequent use when logging in.
I think It's a cause why apple didn't add a new password to the Big Sure - may be they have some strange problems with creating new record to the keychain using cocoa autofill.
In Zeplin app guys use such workaround as a native login and website registration - so safari creates a record in the keychain, app uses auto fill to login.
I'm pretty sure they'll add a new password in the next versions of the mac os, but it would be better if they finish this feature completely and then release it. They just killed the ability to use it normally in the next version of Mac OS because previous versions (like the current Big Sur) support it poorly.
PS
If a user has a lot of passwords from the current domain and he quickly drives in a password, then there is a high probability of an emergency disconnection of the provider (pop-up).
Note: This answer applies to iOS and UIKit, not macOS
I agree with Alexander, please don't :)
But if you must, it would stop from offering autofill by setting the fields UITextContentType Value property to either .newPassword or .oneTimeCode as described here.
After some reverse-engineering, I've found that the following subclass will disable the autofill behavior:
#interface NoAutofillSecureTextField : NSSecureTextField
#end
#implementation NoAutofillSecureTextField
- (BOOL)_isPasswordAutofillEnabled
{
return NO;
}
#end
Related
I am trying trying to bring an application that is in the background to the foreground by binding to a key-press from the user even when the application does not have focus.
The affect I want is exactly like Quicksilver / Alfred / Spotlight.
Is it possible to do this without having the user mess with any Settings inside Accessibility?
Or is this functionality prevented for security reasons? It seems some people have managed to get around this
Thanks!
PS: I am working off the example from apple with rounded window / transparency:
https://developer.apple.com/library/mac/samplecode/RoundTransparentWindow/Introduction/Intro.html
Registering a Global Event Listener is what you're looking for.
You can then read global key presses and call [NSApp activateIgnoringOtherApps:YES]; on the desired key press.
If you also want the user to be able to customise that shortcut, use MASShortcut.
A quick search of Apple's Human Interface Guidelines and Developer Library yields an unequivocal guideline:
Users, and not apps, place menu bar extras in the menu bar.
Anecdotal data backs that up: submitting an app where - upon quit of a dock process/main view, the extra is left running - yields a tidy rejection.
Now - I'm a User experience designer (UXD) who typically plays, I mean, works in the mobile and web space. So please pardon my lack of Obj C chops, thanks.
I understand well the guideline and behavior/pattern: apps like Skitch, Wunderlist, Evernote, et al however very clearly leave the extra (often termed HelperApp) running in the menu bar on quit of main app. They all, do offer explicit user toggle of this w/i preferences.
There's no additional Human Interface Guidelines w/ specifics around handling this requirement for user control. Must this be included in onboarding? Dialog at 1st quit? Again: I can speak to best behavior UX wise, but my (very senior) dev wants the mandate - how are others not getting rejected?
Focus: what means of user control is/are mandated to avoid rejection?
Known/given: include in preferences
Other: ???
After hours of searching online and Apple Dev guidelines, I humbly bring this question here. There simply isn't time to play a carnival game of requirements: guess, get rejected, repeat. Thanks in advance.
Do you have a button somewhere in your user interface that adds the menu extra to the menu bar? Or does your app just do it automatically without the user telling it to do so?
I think that's the distinction, your app must only add an extra when instructed to do so. Also if the primary purpose of your app is to create a menu extra (eg, I have one that puts a calendar in the menu bar) then just launching the app is an implicit instruction, so it can be added automatically.
Ultimately, this rule really is vague and can't be clarified. What it comes down to, is that there should not be many menu extras in a user's menu bar unless the user explicitly chooses to have them. So unless your app really needs a menu extra, you must disable it by default.
If you think the reviewer should have allowed your app through then reply to the rejection explaining your position. I've had an app change to approved once after doing that.
If they still reject your app, then you can appeal the app rejection.
Alternatively, just disable the menu extra by default and have a button somewhere to add it to the menu bar.
Also, all of this assumes you are using NSStatusItem and not the "real" menu extra system — which is a private API. Only NSStatusItem menu extras can be placed in the app store as far as I know.
I am implementing a simple webview application with only one url. I have over ridden back button function for webview navigation (which is working fine). Now my app has only one screen with webview and user visits the links inside main url and navigates using back button.
I want to know that, What is Microsoft Certification Policy as my application has only one screen so should it Close when user press back button anytime? Or Microsoft allows implementing of webview with over ridden back button functionality.
If question is still unclear Kindly tell me. I'll explain more but I need to know answer to this question.
Thanks.
You shoulld be fine, I have submitted applications which works like that myself which passed certification.
As long as the application quits when pressing the back button when there is no more "history" for the webbrowser control it shouldn't be a problem because the user still get the experience of moving "backward" in his use and can finally quit the app.
Regarding WebBrowser control and content of the app please consider this requirement:
"Your app and metadata must have distinct, substantial and legitimate content and purpose. Your app must provide functionality other than launching a webpage."
So, the application's sole functionality must not be only to launch a website.
This is not releated to back button but very important thing that need to be considered!
Best regard
I am implementing a text service on windows. Things work fine. However when I shift window focus to another application and shift focus back to the original application, the selected text services gets de-activated (I notice a call to ITfTextInputProcessor::Deactivate). I think this call is unexpected. Post this call, The service has to be re-activated manually. I am surely doing something goofy. Just that I don't know what it is.
Offhand, I'd say that you are indeed doing something goofy. :) In particular, I'd pay careful attention to your ITfThreadMgrEventSink::OnSetFocus implementation (and, obviously, you need to implement ITfThreadMgrEventSink in your text service and connect it via AdviseSink if you haven't already.)
After more research, I've figured out what’s happening:
When you set focus back to Word, TSF gets the current thread’s active keyboard layout (actually a locale ID).
It then compares that keyboard layout with the language ID of the currently active text service.
If they’re different, TSF then activates the text service for the active keyboard layout, and deactivates any previously active text service.
I believe this behavior is different on Vista/Windows 7.
The fix would be to use LoadKeyboardLayout/ActivateKeyboardLayout to set the process keyboard layout in your ITfTextInputProcessor::Activate implementation. Apparently some apps also need you to call ITfInputProcessorProfiles::ChangeCurrentLanguage() as well.
How would I go about locking a screen like Keychain does, meaning preventing all access to Dock, menubar, desktop, etc. Basically just a black screen that I can add a password field to, for the user to return to the desktop? I am well aware of the Carbon method, but I want the NSApplication method because this is an all Cocoa application.
Thanks~
If you can get away with not writing this code yourself, all for the better. It is usually a terrible idea to write your own code to lock the screen, considering the number of vulnerabilities that have been found in screen locking code over the years. If you have a Carbon call that can do it, go ahead and use that... don't worry about the "purity" of your Cocoa code.
However, if you decide to write this yourself, here's what you do:
First, capture all the screens using CoreGraphics. See: http://developer.apple.com/mac/library/documentation/GraphicsImaging/Conceptual/QuartzDisplayServicesConceptual/Articles/DisplayCapture.html
Next, create a new NSWindow and put it in front of the window that's used for capturing the screens. You'll have to call a CG function to get the "order" of the black window covering each screen, and order the new window in front of that. Normally, the black window has an order so far forward that everything is behind it. Put a password field in the window. Do NOT use an ordinary text field or write your own code for password input. The password input field has a ton of special code in it so you can't copy text out of it, and other programs can't listen to keystrokes while you're typing into a password field. So use the one that Apple provides.
Last, put the computer in "kiosk mode". This mode allows you to disable alt-tab, user switching, the menubar and dock, and even the ability to force quit. See: http://developer.apple.com/mac/library/technotes/KioskMode/Introduction/Introduction.html
It's not a lot of code, it just uses a few different APIs so you'll spend most of your time bouncing between API docs. I suggest writing the screen lock code as its own application (just add a new application target to your Xcode project) and then put the screen locker inside your application bundle. This used to be (as of 10.4) how Apple Remote Desktop implemented the "Lock Screen" functionality, but I can't find the app anymore.
I believe the Cocoa replacement to the SetSystemUIMode API was not introduced until 10.6.
If you can live with Snow-Leopard-only code, the answer is - setPresentationOptions: on NSApplication.