Tahoe Broke Resizing Finder Column View
At the bottom of each column is a resizing widget that you can use to change the width of the columns. Or rather, you could use it to change the width of the columns. On macOS Tahoe, the horizontal scroller covers the resizing widget and prevents it from being clicked! Compare with macOS Sequoia, where the horizontal scroller and scroll bar are below the column and allow access to all of the resizing widgets.
[…]
Notice what happens when you use the default value: not only do the scrollbars disappear, the resizing widgets also disappear.
You can still resize the columns, though, by hovering over the horizontal column border lines. Thus, it appears that the Finder team did not even test with the combination of columns view and always show scroll bars.
That’s the problem with settings like Show Scroll bars: Always and the accessibility display options. They’re there because a vocal minority wants them and Apple feels it has to offer them in order to check a box, but it’s clear that its heart isn’t in making them great. Another one I’d put in this category is Natural scrolling. There’s nothing wrong with its behavior, as far as I know, but you can tell from the name that Apple doesn’t want you to turn this off. The Smooth scrolling checkbox was removed long ago, though thankfully the user default to turn it off still works in most cases.
Previously:
- The Struggle of Resizing Windows on Tahoe
- Liquid Glass Disbelief
- Stop Smooth Scrolling in Safari 16.4
Update (2026-01-23): John Gruber (Mastodon):
I joked last week that it would make more sense if we found out that the team behind redesigning the UI for MacOS 26 Tahoe was hired by Meta not a month ago, but an entire year ago, and secretly sabotaged their work to make the Mac look clownish and amateur. More and more I’m wondering if the joke’s on us and it actually happened that way.
Another change from Sequoia to Tahoe, brought to my attention by Gruber, is that the Finder scrollbar on Tahoe is darker than on Sequoia, the latter shown below.
I believe the difference is due to the lack of a scroller hover state on Tahoe. On Sequoia and earlier, the scroller becomes darker when you hover the mouse pointer over it.
[…]
Both Gruber and the tipster mentioned to me that my inaccessible column resizing widget bug is “fixed” on macOS 26.3.
[…]
Returning to the inaccessible resizing widget issue, on further investigation it turns out that the issue does not occur on macOS 26.2 if you hide the path bar and hide the status bar in Finder.
He also discusses the new Resize columns to fit filenames option, which unfortunately only considers the filenames that are currently in view, not all the ones in the folder.
Previously:
Update (2026-01-26): John Gruber (Mastodon):
This new feature in the Tahoe Finder attempts to finally solve this problem. I played around with it this afternoon and it’s … OK. It feels like an early prototype for what could be a polished feature. For example, it exacerbates some layering bugs in the Finder — if you attempt to rename a file or folder that is partially scrolled under the sidebar, the Tahoe Finder will just draw the rename editing field right on top of the sidebar, even though it belongs to the layer that is scrolled underneath.
[…]
I wish I could set this new column-resizing option only to grow columns to accommodate long filenames, and never to shrink columns when the visible items all have short filenames. But the way it currently works, it adjusts all columns to the width of the longest visible filename each column is displaying — narrowing some, and widening others. I want most columns to stay at the default width. With this new option enabled, it looks a bit higgledy-piggledy that every column is a different width.
Also, it’s an obvious shortcoming that the feature only adjusts columns to the size of the longest currently visible filename. If you scroll down in a column and get to a filename that is too long to fit, nothing happens. It just doesn’t fit.
Update (2026-01-27): John Gruber notes that there’s a hidden preference to auto-resize columns on macOS 14 and 15.
Update (2026-01-30): Adam Engst:
It’s not quite “currently visible,” since the column will resize appropriately for long-named items that are one or two items outside the current view, but I think I understand why the feature works this way.
You have long been able to drag a column divider manually to expand it enough to read a heavily truncated filename, and if you Control-click a column divider, you can choose from Right Size This Column, Right Size All Columns Individually, and Right Size All Columns Equally. Even better, double-clicking any column divider is the same as choosing Right Size All Columns Individually. That command has no limit on column width, and it too expands columns only enough to display the currently visible items without truncation. This approach makes perfect sense, since the user is invoking the command to adjust what they’re looking at.
However, when “Resize columns” is working globally on all column-view windows, limiting column expansion to the visible items makes less sense.
[…]
I think Apple is trying to thread the needle between a global feature that works automatically and one that users can trigger on demand. When applied globally, it makes some sense to tread carefully around unknown extremes; when invoked manually, it should just do what the user expects.
Update (2026-02-05): Marcin Wichary:
Apple decided not to ship the auto-sizing columns a few years ago, hiding it under a “defaults write” incantation as a sort of a beta, but then seemingly just launched it this year without any changes. There are some charitable explanations – perhaps the beta was hard crashing Finder and the released one no longer does? – but in the current zeitgeist I’m feeling that it’s something more like this: the people with taste who were stopping it from getting launched in the bad state were either sidelined or are no longer there.
Update (2026-02-20): Jeff Johnson (MacRumors):
In today’s macOS 26.3 update, Apple implemented a “fix” for an issue I blogged about a month ago, macOS Tahoe broke Finder columns view.
[…]
The scrollbar unfortunately still covers up files in the columns. However, the vertical scrollers have been shortened, so the resizing widgets are now accessible above the horizontal scrollbar.
Problem solved, right? Well, not exactly. Try hiding the path bar at the bottom of the window[…]
It was downright broken in earlier versions of MacOS 26 — you literally could not resize the columns. So now it’s not broken. But as Johnson says, it looks silly and amateurish.
This is the sort of detail that Apple used to strive to get pixel-perfect, all the time, for all settings. “Whatever, good enough” instead of “insanely great”.
But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.
I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.
Previously:
12 Comments RSS · Twitter · Mastodon
"Natural Scrolling" is another clear indicator that Apple hates the mouse. It's the nautral direction on a trackpad. It's entirely unnatural on a mouse wheel. It would be so easy to split those options so you don't have to have it broken for one or the other, but Apple just doesn't care.
@bart Natural scrolling does feel natural with a Magic Mouse, though. I think they should split the options (because otherwise it’s punitive to ever use a non-Apple mouse), but the Magic Mouse should either be treated like a trackpad or be a third type…
Another problem is that it looks like the setting is split because Natural scrolling shows up separately in the Mouse and Trackpad panes of System Settings, but actually they are linked and changing one changes the other, too.
Another Tahoe horizontal scrollbar thing: in Music, now that the main controls have been moved to the bottom of the window, overlaid on the contents of the main window, if there's a horizontal scroll bar that appears *above* the controls, instead of at the bottom of the window. Looks very odd.
Mos is a great utility for people who use both trackpad and mouse on the same machine. Allows defining the scroll behavior for each.
I'm a couple of weeks into having "upgraded" to Tahoe from Sequoia and ran into this problem a few days ago. This issue of not being able to resize columns has me seriously considering going back to Sequoia, for which I would basically have to blow up my current setup and start over from scratch. This may be the final straw after encountering so many other issues. I had never used Feedback Assistant before and so far with Tahoe, I've submitted close to a dozen obvious issues.
I installed the iOS 26 public beta on my phone last year and after a week, I couldn't take it and went back to iOS 18 after wiping my phone (I foolishly didn't have a saved iOS 18 backup). That was painful.
It's hard to overstate the lack of confidence I feel about the state of Apple's software. I used an Apple II in school and when it came time to buy the next computer in the mid-90s, I chose a Windows PC because the Mac did not seem like a good value and my family really couldn't afford one. Plus the writing was on the wall that Apple would be dead (and turns out it was close!).
I switched from Windows with Mac OS X 10.1 in 2001 and never looked back, but now I feel despair. Starting with Tahoe, I actually dislike using my computer now (which I have to for my work), and alternatives don't look any better. Perhaps it is actually grief I feel. It's hard to move toward acceptance knowing that we'll have to suffer through years of iteration before the problems that weren't problems before get ironed out. But I'm also worried that maybe we haven't even hit bottom yet.
I've never understood the controversy about "natural" scrolling. I use a mouse with a scroll wheel, and a trackpad on the same workstation, and "natural" scrolling is on for both.
I think the problem is nomenclature, "natural" scrolling should have been labelled "Direct" scrolling, and the traditional, "Indirect". That's the difference between them:
- Natural (Direct) scrolling, you're manipulating the content itself, the scroll wheel or trackpad surface is the actual surface of the thing being moved, and you're pushing it up or down in the viewport. It's a very strong proprioceptive-linked interface.
- Traditional (Indirect) scrolling, you're pulling on a window sash cord (the scroll bar), which is attached to the content after going over a pulley at the top of the viewport, so you pull down on the scroll bar, to lift the content up.
I don't understand why Apple didn't make that distinction clear and it goes to their worst instincts to try to change the definition of existing things ("natural"), rather than give new things new names, because it seems to have caused real consternation in a certain part of the userbase, but perhaps mostly amongst people who don't only use Macs so they're forced to go back and forth between Directly and Indirectly scrolled operating systems.
@Someone
I think that's a bit of an obtuse description of traditional scrolling. Really it's just indicating the direction you the viewer want to move in the document. Up means up, down means down.
The appearance of the document moving downward happens for the same reason that the world appears to move downward when you travel upwards in an elevator. So it's all just a matter of perspective, and what your brain wants to imagine is actually moving: you, or the thing you're looking at.
This is the same issue that people have with flying controls or camera controls in games. Are you indicating which direction you want the world itself to move, or the camera / tip of your airplane? Every game developer worth their salt knows their game needs to have an "invert Y axis" setting for any vertical controls, because different people simply require different things, and there's no getting around it.
It is infuriating that Apple has, to this day, maintained one setting for scroll direction that doesn't distinguish between a trackpad, magic mouse, and conventional scroll wheel. There's no good excuse for that. Chalk it up to incompetence or malice as you wish, it's at least one of those if not both.
Apple thoughtfully (this is sarcasm) provided the choice for VoiceOver users using the trackpad too. So now up means down, and down means up, in a context *completely* free of visual cues or a mental model of how the direction relates to the gesture beyond the documented "natural" default. I think they see "natural" scrolling as a distinction, not merely a user convenience. But, being blind, it's interesting to understand the visual perspectives on this.
And who is this "vocal minority"? Are they the right-thinking Apple users of yesterday, or barbarians, or what?
@Bri An obtuse description, maybe. But the physical metaphor is how people understand the difference, because both perspectives of the debate will say they're "correct" as if their chosen format is some law of nature.
Just calling it "natural" doesn't explain anything.
In "natural" scrolling, I pull the content down, and the content moves down.
In "not-natural" scrolling I push *up* on the content, and the content moves down. The opposite to what my proprioceptive experience tells me I'm doing. No one is going to conceptualise it as "i'm scrolling my entire computer up and down over a static document, it's not like the elevator example, because the user has a proprioceptive experience of being static, so it is always the document being moved, not the perspective changing.
From that perspective, "natural" is a good word for it, but you can't just define a term based on a good word for one side of the toggle option, what's the proper name for the other setting, "un-natural"? Traditional?
Direct and Indirect work because they indicate the way the function effects the target, and they're not *as* inherently value judgments, the way "natural" and "un-natural" are.
This scrolling fail started with 26.2, did not exist in 26.1. I did not test in 26.0, but I suspect it was broken only in 26.2 (how does Apple break something as basic as scrolling when it worked in prior versions??)
A client actually alerted me to the bug after the 26.2 update, and they were forced into Tahoe upon release. Disabling "Always show scrollbars" again allows column resizing, but without an Apple mouse (as mentioned) it's pretty difficult or impossible to horizontally scroll without scroll bars. Shift-scrolling on many scrollball/wheel mice only moves a tiny fraction of the vertical speed. Not sure why it has always been like that on Mac, but there we are. Don't buy Apple, get penalized!
As for scrolling paradigms, I come from a mouse scroll-wheel tradition, therefore it is completely unnatural for "natural scrolling" to apply to me. It's the flight-stick mentality that fits in my mind. I don't have a problem when it's a direct touchscreen experience, but any abstracted device only feels right when it's set to the older method. When I have to work on others' computers, I find myself just randomly scrolling until I get where I need to go, and my productivity suffers. When I get back home, all is well, and I don't find myself guessing, anymore. We need OPTIONS, Apple. Get with it or we're leaving for Linux (I've already started, m'self.)
The new option to "Resize Columns to Fit File Names" is also broken, because it only resizes based on the file names *currently* in view, NOT the longest file name in the entire folder.
Like... what??? So you select this option, then scroll down and the longer file names are still truncated which is what you were explicitly trying to avoid.
It's like they have kindergartners steering this ship now.
