Mac: Keyboard Shortcuts Killed by Bug
eclecticlight.co
eclecticlight.co
Every OSX engineer probably has more bugs on their plate than can be fixed in one career, in addition to feature development tasks. The OSX team is severely understaffed both because it is not a priority at Apple, and because it is getting harder and harder to find engineers that are able to/willing to work on this kind of code - a Byzantine labyrinth of C flavors that's been accreting lines for decades.
The OSX team is in a desperate fight for recognition and status against the iOS team. They believe (and are probably right) that the only way to gain executive mind share there is to build out new visible features, no matter how useless. Witness dark theme, stacks, dynamic desktop, siri on the desktop, a steady stream of useless iPhone integrations, etc. All the troops are ordered to march relentlessly toward feature development. Stability and bug fixes be damned.
It bet it takes at least three weeks of focused effort and red tape macheteing to fix this bug and it is way down on someone's list. Even if you fix it the change won't make the next OSX key note at the annual IOScon or whatever it is called, so it won't help your career one iota.
Again - this is just how I imagine it is there. I don't really know.
A fight for attention by a specific, resource-starved macOS engineering team could not be more incorrect. That’s simply not how Apple works. You have to come up with a different explanation for these perceived quality problems.
The developmental move to agile deadline-driven feature-sprints under Craig Federighi.
The way to think about this is that the menu bindings are AppKit features which share resources with UIKit.
An interesting theory would be one which identifies (i) who in the organization gets to gate what ships and decides it’s good enough (ii) what are their incentives. At a company like Apple which is huge, has marketing deadlines, and is coordinating hardware, software, and services releases, both items have very subtle and interesting answers.
I've also experienced very few bugs in MacOS which have affected me on a day to day basis. Not saying they aren't there, but to me the MacOS team are doing a pretty great job.
In particular, zoom.us, our teleconferencing solution, crashes them regularly with spewed messages about GPU stuff in console. We're about at the point of running windows vms so my salespeople can have a reliable conferencing solution.
The keyboards also do not hold up at all. I've gotten into a shouting match at an apple store after buying their "warranty" and learning that a keyboard repair would mean the laptop would disappear for a week. That's not a warranty; that's some Dell consumer-grade bullshit. I basically had to buy a floater laptop on the spot. Two of the laptops, including my cofounder, have keys that don't work, but they're too busy to deal with Apple's bs to get them repaired. I'm aware that after the WSJ embarrassed them the wait is supposedly shorter, but it's not anything reasonable. They should be able to do a keyboard swap in an hour while you wait.
Their busted ass OS also has automatically (!!!) disabled Filevault, refused to turn it back on, including spending 6 hours on technical support and an OS wipe. We had to take that laptop into the mac store for them to service. Folks, don't wait on installing an mdm -- just because you turn Filevault on, it can silently disable itself.
Apple's keyboards used to be excellent. After the new keyboards came out a few years ago they've been delicate (I've come around on my opinion about how they are to use--but I'm still not a fan of the layout). Replacing them is also a nightmare. So far a keyboard cover has seemed to not have me baby it and prevented a repeat of any issues.
For consumer grade stuff, I'm not a fan of Dell. But their business laptops and support services are solid, from what I've seen.
I haven't experienced any of the other vendors, but any vendor with a business line (such as HP or Lenovo) have similar support services. And just as critical: they design their business laptops with that need in mind. If you pay for a service level that includes on-site support, very few issues are un-repairable by a field technician. And they even make access to things like the hard drive easy, since corporations don't like to relinquish control of potentially sensitive business data.
Apple offers enterprise support[2] (not sure if that's an indication that the service is priced out of the SMB range) with similar onsite services. But their machines aren't exactly designed to be easily repaired. So if an Apple Store would have to send it off to a repair depot, I doubt a field technician would be able to do much more.
[1] https://www.dellemc.com/en-us/services/support-services/pros...
The MBP I had previously (same model, exchanged out due to keyboard keys sticking) did the same thing.
Additionally I find if the battery hits 5%, it doesn't actually register that it's charging in time to save it. Fair enough, but call it zero (so implicitly I'm warned earlier).
- I upgraded to 10.13, and my stock graphics cards would slow, freeze, and then crash window server, logging me out. I spent the money to buy a hot new GPU from Apple's latest recommendation list, and it no longer crashes (though I'm having trouble getting both of my Apple displays to work, since apparently most of the "DisplayPort to dual-link DVI" adapters in the world are actually single-link).
Other issues I've run into recently with new or revamped features:
- Dark mode works great sometimes, and other times it's an unreadable mess.
- Xcode 10's new text editor broke control-T, which has worked correctly in every text field since the earliest days of Mac OS X.
- The new security around contacts/calendars broke my app. It doesn't work like it used to, it doesn't work like the documentation says it should, and it doesn't log anything useful to help diagnose the problem.
- The recent documentation, overall, is a big step down. developer.apple.com used to have long-form articles describing how things were built. Now, it's mostly just HTML versions of header files, and half the descriptions are "No overview available."
- The new WKWebView teases improved performance (and not being deprecated, like WebView), but removed major features I was using, or planned to.
- Dragging toolbar items in Safari 12 seems completely broken.
- You can set almost any accessibility option via script, except menubar transparency, for no apparent reason.
It was no coincidence that Macs used to be simple. "Simplicity is prerequisite for reliability"! When you've got only one color scheme, you can make it 'just work' everywhere. Once you've got more than one color scheme, now you have to go check everything to make sure this doesn't happen: https://twitter.com/KenHatesSoftwar/status/11059512173713530... (which depends on the dark-mode setting, the reduce-contrast setting, the desktop wallpaper setting, ...)
Multiply this by every permutation of settings. I don't think it's feasible any more for single-developer Mac shops. There just aren't enough hours in the day to make everything work well. Even Apple is struggling.
My next project isn't another Mac app. It's a web app in Clojure. CSS is still terrible to work with, but (with grid and flex) it's slightly less awful than it used to be, and much more consistent. And Clojure is infinitely more pleasant than Swift.
I couldn't believe this, so I tried it. To clarify: in Xcode 10.2.1, typing control-T between two characters in a line exchanges the two characters, as expected. But typing control-T at the end of the line does not perform the special case of exchanging the two characters at the end of the line; instead it exchanges the last character of the line with the newline, thereby moving the last character onto the next line. Off to bugreporter...
Yes, there is feature creep and it does have a bit to do with executive mind-share. But don’t attribute to greed what you could attribute to the age old problem of managing software complexity.
The way to win the game is to not play.
In the Scott Forstall days, there was a distinct iOS team (Scott) and a distinct OSX team (Craig). now there isn't.
Frankly, maybe that's exactly the problem. He left in 2012, and that definitely feels like around when things started going downhill.
I don't know what stuff is like under the hood, but from a user perspective, iOS and macOS are two very different platforms that are good at very different things. I'm sure there is a lot of tech that can be shared between them, but some individual focus would likely be beneficial as well.
And if those "other responsibilities" are iOS, tvOS, and watchOS, then there is no "macOS team." There is the software engineering organization.
Apple slices up departments by function, not by product, which is why there are organizations under Tim Cook such as Software Engineering, Hardware Engineering, Internet Services, etc. Everyone and no one is responsible for shipping all the products as a result of this structure. Software Engineering in particular is responsible for all of the operating systems that powers Apple hardware.
Similarly, this is how smaller departments under each SVP/C-level org are subdivided, and so on to the team level. Each team may be responsible for a particular product, which includes all the experiences for that product across operating systems. There is no single engineer responsible for just macOS/iOS/tvOS/watchOS. Everyone is responsible for everything, and similarly no one is responsible for anything.
Apple's structure is unique compared to other companies, and contrary to how most are run, which probably contributes to your confusion.
Apple is a phone manufacturer. Computers are a side business.
But given that developers have no choice in the matter, they’re stuck putting up with whatever issues Apple doesn’t bother to fix. I’m sure Apple is well aware of that when prioritizing what bugs are important.
[1]http://cdn.arstechnica.net/wp-content/uploads/2016/04/Apple-...
I get that Apple makes more revenue from other products, but the Mac is still extremely profitable. They ought to give it some attention on those grounds, if nothing else.
> This isn’t an Apple which has any concern over the quality of its products, or for its users. It’s just another leviathan corporation which has stopped caring or taking pride. One small bug reveals a deep and pervasive problem.
I'd rather see a more measured approach to drawing conclusions from a single anecdote.
At some point, the back is broken, the developer gives up on trying to help an obscenely profitable company QA their own products, and rants about the lack of care being shown.
I attribute this to improvements in the reliability of Airplay: my machine used to be prone to crashing after connecting via Airplay (either sound only or mirroring) to my old Apple TV.
I'm sure other things have been broken along the way, but it seems to me like Apple is tackling hard problems at the OS level and making progress.
Personally I've introduced bad ... choices because I cared about users a few times. It just was a mistake on my part, and yet the whole time I was thinking "this will be better for the user".
To be fair, a lot of people choose OSX over other OSes because Apple has the reputation of "sweating the details" in both their software and their hardware.
Some of those people in particular are now noticing that the attention to detail may not be like it was, so it is unsurprising that some are complaining over seemingly little things even when the product as a whole might still be better than its competitors.
Expecting the customers of obscenely profitable companies to QA that company's products (for free) is silly.
>slipped through
At what point do we hold companies responsible for their products? At what point should we, as software developers, hold ourselves responsible for our products?
I think it's entirely reasonable to answer "when the company is a multinational, highly profitable company" and "when they are among the brightest software developers in our generation"; "another bug" "slipping through" should not be considered to be acceptable.
If I toggle to dark theme, I can reproduce it, but not in a consistent way. Depending upon how I add and remove shortcuts and toggle themes, I can get just the last shortcut to display incorrectly, or all of them to display incorrectly, or none of them to. It's some odd interaction between dark/light themes and this panel.
> There is, still, a long-standing MacOS bug where your balance may drift when volume buttons are pressed while CPU is under heavy load.
Sure it is. OP is an outlier in how they use this panel. Most people just use it to enable/disable the built-in menu commands, or to modify their accelerators.
One very common use-case for people who speak multiple languages is enabling the keyboard switcher accelerator. I expect that they have extensive tests for common use-cases like that.
On the other hand, I expect that the test suite they use probably only tests creating one or two custom keyboard shortcuts using the panel; and doesn’t give them overly-long names. UX integration tests, above the level of the control library itself, aren’t usually concerned with being fuzz tests on what happens when you have a whole bunch of something (long strings, many items) loaded into a control. Normally the control library itself takes care of that for you (and has its own trustworthy fuzzing/property-testing suite), so you only worry about ensuring that your view controller gets the data into the control’s data binding in the right way.
I would guess that this bug is there because the view controller is summing up the lengths of the strings under a given section for some task; and then, later on, accidentally using that sum-of-lengths as the determinant for whether each string is too long to fit into its column and needs ellipsis...ing (eliding? elision?), rather than using each individual key’s length. Totally plausible bug, it makes total sense that this is an old bug that nobody discovered until now. It would seem that literally nobody has tried to do this until now.
Still, this is the type of thing that’ll get fixed immediately if you file a Radar on it. Whatever the underlying problem is, it’s on the view-controller layer, and definitely a simple fix; and there’s no decisions or opinion required on what the fix should be; and it doesn’t require any specific expertise (like having knowledge of the kernel.) It’s an “easy win” ticket someone would likely knock out the same day you submitted it.
The fact that it didn’t get caught during any of the numerous betas since Sierra, really, really implies that nobody ever thought to try this—users or developers. (Because if someone did report this bug in the beta, and it was still in the prod release, you can bet they would have blogged about it when that happened.)
There is another explanation. The author says that he was able to reproduce it always, but I use this feature all the time and I don’t have that problem, so probably there are other factors that cause the bug.
You asume that nobody uses this feature, because probably you don’t use it and because the author says that the bug is easy to reproduce. But without meaningful data is hard to say.
For example, most of the shortcuts that I put there are for Sketch, and AFAIK many designers using Sketch use this feature.
Apple is an exception, which is why it's so fascinating to study.
Why can Apple get away with bugs and overly expensive products?
I'm 50/50 on this. I think the primary reason is marketing/psychology tricks to make Apple users feel happy. Or Apple has created an ecosystem that is impossible to leave.
I'm just glad I never fell for it.
This isn't how Radar works :(
Does this author really think that every developer, after every code commit, and before every release, manually goes through every single piece of functionality in an entire operating system, in every possible configuration, to ensure nothing regressed? That just does not happen. Either they write regression tests, or they document a feature and have QC evaluate it. But both of those can be error-prone, bugs happen, and there is absolutely no indication that anyone knew about the bugs. Refusing to report them because "they should have known about them anyway" is childish.
macOS has a handy "Batch rename" feature in the contextual menu when you right click on files. The renaming GUI gives you options for sequential numbers, text replacement, prefixes, suffixes, inserting dates.
But the menu to open this is called "Rename X Items…" so you can't assign a keyboard shortcut to it. Might be 5 items, might be 2914 items. Without wildcards you'd have to make a different shortcut for every different quantity.
I love Applescript. My entire home entertainment setup basically runs on Applescript—each button on my Harmony remote triggers a different script.
There's no equivalent on Windows—you can use Autohotkey, kind of, but without any sort of Apple Event-esque specification it isn't nearly as useful/nice.
Upon adding the third shortcut, the display of the "menu" name, indeed, shows as an ellipsis. But:
(1) the name is still visible through a tool tip (2) when I close the window and reopen, thingS display fine. (If I start editing again, I can get some weird ellipsis display again, though now by deleting items rather than add thing them)
Anyway, definitely a bug, but at least for me it's pretty easy to work around, so a pretty minor bug in a minor feature.
Both of these statements are false.
that makes no sense at all looking at the behaviour described. if you want to write an article complaining about someones business processes letting through unacceptable bugs, make sure you understand what is a computer. then perhaps learn to debug issues on it. once you can do that, perhaps you will be less tempted to write such a mess.
You used "lol" in written communication which makes you sound like a 12 year old girl texting her friends.
You then continued in mid stream and concluded a sentence that you never began.
You said "make sure you understand what is a computer" which makes zero sense whatsoever and joined several sentence fragments with periods.
Perhaps before critiquing someone else's communications it would be optimal if you were to improve your own.
Your entire communiqe could have been written like do.
"The author does not appear to understand how the software he is using actually works, perhaps he ought to clarify his understanding before writing so unclearly about it."
It's not clear what was gained by your point-by-point rebuttal (of presentation rather than content), but it was worth it for this unproofread line.
(This is not to defend Apple's responses to Radar reports; I think probably anyone here has one or two sore spots of years-ignored bug reports. But at least they're there!)
I've done `defaults write -g KeyRepeat -int 5` or something like that and it kinda works but somehow doesn't feel "right" still. Am I missing something obvious?
15/2 is beauty. Thanks a lot!
https://bugs.chromium.org/p/chromium/issues/detail?id=892480
Bugs happen, it doesn't necessarily indicate anything systemic.
Go one level deeper and open "Activity Monitor" and look at the energy impact for the apps you are using. Unless you use Safari, which is wonderfully energy-effecient, then the most likely culprit is your web browser, especially if you're using Google Chrome. Personally, I'd use Safari over Chrome for the energy efficiency alone, but I understand people have different priorities.
You can also check the health of your battery by doing "Apple Menu" -> "About This Mac" -> "System Report…" and then selecting "Power" in the side bar. (Google for the expected charge capacity for your laptop model.)
Try clicking the battery icon ;-)
Fun game: try to remap Ctrl+a to select all, Ctrl+c to copy etc to mimic unix/windows. (or god forbid, to make your limited mobility device that cost thousands of dollars several years ago to work on your work provided macbook pro)
Every single app will behave differently and you will see how broken usability/accessibility is on OSX. Some examples for Ctrl+c:
on Firefox, Ctrl+c will move the cursor to the end of the text area while cmd+c will still work as copy, despite the menu hint showing Ctrl+c next to edit>copy.
On Notes.app it will work fine and cmd+c stops working (correctly).
On safari, calendar and most apple office stuff ctrl+c just do absolutely nothing. In some apps it shows ctrl+c next to edit>copy though, because why not
System Preferences > Keyboard > Keyboard > Modifier Keys...
In this dialogue you can remap what the modifier keys means, so you can make the ctrl-button act as cmd and make the cmd-button act as ctrl.
Personally i use it to make the caps-lock key act as escape.
See also "DefaultKeyBinding.dict" for more keyboard behavior possibilities, including stuff like ^W and ^U working in Cocoa text fields.
Hmm, I still have my main machine on High Sierra due to nVidia drivers (and Mojave's Apple Event Sandboxing being a giant PITA), and I can't replicate this on 10.13.6. The bug worked on my Mojave machine, however.
I wonder if the author is mistaken regarding how long the bug has been present. Or maybe it was introduced in 10.13.4, got fixed, and then was broken again?
This is both a large assumption and a huge oversimplification. What about time to regression test, QA, deploy through the various inner rings/dogfooding groups, check accessibility, etc.?
It smacks of a writer who possibly has coded before as a hobbyist but never professionally.
And this has been in place since Sierra?! Wow!
I'm not convinced that Apple actually knows about this bug, but what does that say about their software testing...
Apple should open source their OS. They would not longer have to waste their time and energy pretending that the MacBook market matters to them. Developers would be happy with them - its a win win situation!!
By the author's own admission (in the comments) this doesn't even seem like a major bug. His refusal to report it isn't helping anyone, and it's a display issue that's fixed by closing and re-opening a window. How was any keyboard shortcut actually killed here? What a terrible clickbaity headline.
can't even touch my mac without gloves