Post not yet marked as solved
…nor does it work in macOS 11.3 beta 2 (20E5186d)
Post not yet marked as solved
Password AutoFill still doesn’t work with Cocoa bindings in macOS 11.3 beta 1 (20E5172i). I filed FB9007031.
There is a workaround—you can observe NSControlTextDidChangeNotifications from each textfield and manually update your string properties.
Example from my bug report:
objc (void)viewDidLoad {
[super viewDidLoad];
if (kEnableWorkaround) {
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(myControlTextDidChange:) name:NSControlTextDidChangeNotification object:self.usernameTextField];
[[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(myControlTextDidChange:) name:NSControlTextDidChangeNotification object:self.passwordTextField];
}
}
/* these will also get called when typing; superfluous when already using bindings */
(void)myControlTextDidChange:(NSNotification *)note {
NSTextField *textField = (NSTextField *)note.object;
if ([textField isEqual:self.usernameTextField]) {
self.username = self.usernameTextField.stringValue;
} else if ([textField isEqual:self.passwordTextField]) {
self.password = self.passwordTextField.stringValue;
}
}
Post not yet marked as solved
This has been bugging me all afternoon. I had also just installed macOS 11b10 (20A5395g).
In a post from 9 months ago, Quinn shows that - https://developer.apple.com/forums/thread/127650 lldb will stop at SIGCONT by default and suggests a temporary workaround:
(lldb) process handle -n false -s false SIGCONT
I tried and failed to get this to work in my .lldbinit, then found this old SO post - https://stackoverflow.com/a/16993602/1034477:
At present the suggestion of doing this in a breakpoint command on main is the most elegant solution available. I added a symbolic breakpoint for main that runs the above debugger command and continues. It fixes the annoying issue of the debugger pausing immediately, although lldb-rpc-server will still use an entire CPU core while doing nothing…
Confirmed & closed FB7568175.
Is there any response for FB7568175?
Nope.
Verified the crash on iOS 12.4.1. You can temporarily work around the crash by dynamically adding the missing _UITextLayoutView class to the runtime on older versions, but who knows how UITextView will behave after that. Please don't actually ship this "fix".I've filed feedback report FB7422472 and encourage everyone in this thread to do the same.
Post not yet marked as solved
Welp, they ended up shipping this! (Has anyone tried the 10.15.1 betas?)On 10.15 (19A602) I found that creating a dummy Assets.xcassets catalog containing a single colorset (so that the catalog at least gets compiled and Assets.car exists in the bundle at runtime) was enough to fix the console spew.
Post not yet marked as solved
This surprised me too. I filed FB6481613.
