[2bitencryption]

The interesting part, for anyone who actually reads the article - the change was fixed in an RC and then reverted in the final release.

Which implies there was some regression, some issue, some incorrect behavior or negative impact. One has to wonder… what could it have been? What could the issue with having a more accurate clickbox for the corner of the window possibly be?

[galad87]

It broke some NSWindow styles: https://developer.apple.com/forums/thread/814798

[hbn]

The sad part is we all know the real solution is to just UNDO THE DAMN FISHER PRICE ROUNDING

NO ONE CARED THAT THE WINDOW CORNER RADIUS DIDN'T MATCH AN IPAD, IT DOESN'T NEED TO

[GuB-42]

It can be some technical detail.

For example: imagine you have 2 windows, the lower right corner of one window almost touching the upper right corner of the other, so that the bounding rectangles overlap but the graphics don't.

With the inaccurate "false square" corners, you just had to check the bounding rectangles, to know which window to resize, now you have to check the actual graphics (or more likely, a mask).

I am not saying it is the problem, but that's the kind of thing that can happen. Or it may be a simple bug, like a crash, memory corruption, an unhandled exception, the usual stuff, but they couldn't fix it in time and it is better to revert instead of leaving the buggy code or pushing an untested fix.

[blindriver]

Just revert the code back to pre-26! This is ridiculous, it can't possibly be this hard and if it is, it just points to the degradation in the quality of Apple software! This is maddening!

[msephton]

I think it shows how difficult it is to ship a seemingly easy thing inside the Apple machine.

I'm more interested in how or why this bug was approved up be worked on so quickly after it was surfaced, rather than other longstanding and arguably more impactful bugs.

[StilesCrisis]

It's because the bug got publicity. Apple marketing prioritizes what does and doesn't get built. Someone saw bad publicity on the front page of HN and requested a fix.

[nozzlegear]

The answer is probably a ho-hum combination of different teams work on different issues, and this one having annoyed one of the devs who could work on it.

[radley]

Most likely (and natural): they tested it publically and the response wasn't positive, so they held it back until they could do it better.

[pdhborges]

Maybe they reverted it because they are already planning to get rid of the super rounded corners!

[cardanome]

The AI reverted the change and no one does proper code reviews anymore so it went into prod.

[adithyassekhar]

Nah then it won't show up in the known issues section. I hope.

[anematode]

Maybe it was just an oversight in the merge process? e.g. the diff was applied only to the RC and not to the release branch? idk

[jlaternman]

macOS does have weirdness with windows that span multiple screens. I bet some of that kicked in to an unacceptable level. It can create incoherent moving/snapping, for example. Has been kind of crazy-making for a while, for my set-up where screens are not joined but adjacent in a triangular configuration.

[iainmerrick]

Yeah, that's something that was unambiguously better back in the "Classic MacOS" days (probably starting with the Mac II). Windows could overlap multiple screens and they were always drawn correctly.

At some point in OS X in the switch to hardware acceleration, they started rendering windows on one screen only.

I get that you hardly ever really want a window spanning two screens, but when you accidentally misplace a window it would be handy to be able to see it on each overlapping screen so you can track it down. Right now you can put a few pixels of the title bar on the wrong screen, and the rest of the window just vanishes.

These regressions are weird given that modern hardware is vastly more powerful than a Mac II.

[lobochrome]

Or it was just a botched git op