Hacker News Reader

Comment by akersten | Hacker News Reader

Ugh, yucky. Surprising lack of quality control on Apple's part - surely they should have tested typing into a text field at some point during the testing; don't most programs register a shortcut key or two?

But there are also some UI fails on Twitter's side here too - like clearing the password field after clicking Show Password and typing more, and preventing arrow key navigation within the field.

View on HN

Not surprising any longer... There's a whole class of Mac Mini's (including the latest revision) where if you install Catalina, the HDMI port dies.

Ya I've seen those, that's completely crazy.

As in, permanently breaks the hardware? Or just won't function with that software version?

"For those that are going to revert back to Mojave as a solution, a number of people are noting that this does not fix the issue (it didn't for me), indicating there is perhaps some sort of firmware update taking place with Catalina that will not be rolled back when you install Mojave."

— https://forums.macrumors.com/threads/catalina-causing-issues...

Rolling back worked for me, but the workaround is using the USB-C to HDMI dongle. (and I think I needed the dongle to downgrade.)

>don't most programs register a shortcut key or two?

Yes which is exactly why I think it's likely he's being disingenuous about the root cause of this. Shortcut keys typically need modifier keys and, even in the instance where they don't, there has to be some check from the app to determine whether an input field or the main window has focus.

To be clear, I'm not saying it's 100% certain that this isn't an Apple issue but, based on Twitter's track record with their apps, this likely is on Twitter.

Are you an iOS/Mac developer? Because in this case it sounds like the UIKit/AppKit isn't respecting the responder chain, which would be an Apple bug.

It's entirely possible where in Catalyst if a UIKeyCommand is registered that uses a non-modified letter, it overrides text input. Having said that, I can't imagine why Twitter for Mac would have solo-letter key commands registered during the login flow, and if they did then I can't imagine why they wouldn't also interfere during tweet composing. Or rather, I can imagine, but the scenarios I'm constructing would imply extremely contorted view controller hierarchies that make no sense.

Can’t imagine why this would cause it to delete all input in the field when one of those characters is typed in using “reveal password” mode though. If you enable reveal, type in a string containing b, and then switch off reveal mode and add another character, it deletes the whole password. If it was just dropping inputs that would be one thing but this seems to be aggressively refusing to allow them in the field.

It sounds like its specific to secure text fields, which I assume is why it doesn't interfere with tweeting. But thats a fair question about setting those up before login. My guess is those registrations aren't happening at the login VC level, or maybe in some global container VC. But I don't think that matters too much, because there are certainly use cases where you might want to show a secure text field even when logged in and you want shortcuts registered.

I am and that's why this is so surprising to me. No other app is reporting this type of behavior and Twitter is known for shitty Mac apps. I highly doubt that the regression could cause this unless it was done incorrectly to begin with. Otherwise, UIKit/AppKit would be doing the same for every other app. We may hear about that in the next day or two but, until that happens, I have a feeling this is all on Twitter.

It looks like its reproducible in a sample project.

https://twitter.com/nolanobrien/status/1189623346033381376?s...

That doesn't mean much if they implemented it in the exact same way they did for the full app. Unless we see this happening in other apps, I'll default to the implementation being the problem rather than the API itself.

Reply on news.ycombinator.com