I’m seeing a window resizing issue in DEVONthink 4.3.1 on macOS 26.5.1.
In List View, DEVONthink can get into a state where the window’s minimum width becomes almost full-screen width. As a result, macOS Window > Move & Resize > Left / Right does not resize the window to half screen. Instead, the window remains nearly full width. However, Top / Bottom works normally.
I tested other apps and they do not show this issue. I also quit Magnet and confirmed the issue still occurs, so it does not appear to be caused by a third-party window manager.
Additional observations:
The issue appears related to List View / column layout state.
Resetting the outline/list view preference temporarily changes the behavior, but Left / Right still does not reliably resize to exactly half screen.
Top / Bottom works because the window width does not need to be reduced.
Are you able to reproduce this using a new, clean macOS user account? Or after booting in safe mode? So far all reports are from users using both window managers (e.g. Moom, Magnet) and macOS 26.5.1.
Thanks for looking into this. I can rule out third-party window managers on my machine:
Window manager is not the cause. I fully quit Magnet and then kill -9’d it to zero running processes (confirmed with pgrep), no
Moom/Rectangle/Yabai/etc. installed or running. The bug persisted unchanged. I also reproduced it without any third-party tool, using only the
native Window ▸ Move & Resize ▸ Left: the window jumps to x=0 correctly, but its width only shrinks by ~8 px instead of going to half-screen —
it stays near full width.
Precise signature (all measured via AppleScript set size and confirmed by hand):
Only narrowing the width is affected. Each discrete resize request reduces width by ~8 px and no more, so any single-operation resize (Move &
Resize, snap-to-half, a one-shot set size) appears stuck near the current width.
Width widening, and height (taller/shorter) work normally, one-shot, as expected.
There is no hard minimum width — if I issue the resize ~50–60 times in a row, it does creep all the way down 8 px at a time. So it’s a
throttle/relayout issue, not a minSize clamp.
Survives a full quit & relaunch of DEVONthink, and survives deleting all saved window/split-geometry keys from the preferences
(ContentsBrowser-*, NSWindow Frame *, sidebar/inspector/split widths). New windows are affected too.
It is DEVONthink-specific: Finder and other apps resize freely in one operation on the same machine.
Environment: macOS 26.5.1 (25F80), DEVONthink 4.3.1, 5K display running a scaled HiDPI mode (“looks like 2560×1440” on a native 5120×2880
panel). I saw another user in this thread mention a correlation with display scaling, which matches my setup — happy to test other resolutions
if useful.
I have not yet tried a clean macOS user account or Safe Mode — I can do that next. Given that a fully-killed window manager and a from-scratch
preferences reset both leave the bug intact, my money is on a DEVONthink-side layout/relayout issue triggered under scaled-resolution displays,
rather than a window manager.
Works absolutely fine over here on a Studio Display using the same macOS & DEVONthink versions and the same window setup. Is this a third-party monitor? Which columns are visible in the List view?
Found the trigger condition and a reliable way to clear the bad state — hope this narrows it down.
To answer your questions: yes, third-party monitor — Dell U2723QX, which is a 4K panel (3840×2160) running “looks like 2560×1440”, i.e. non-integer scaling (5120×2880 backing store downsampled to 4K). Your Studio Display at 2560×1440 is exact 2x — that’s likely why you can’t reproduce.
Controlled test results (all via scripted set bounds, same machine):
At 2560×1440 fractional scaling: narrowing creeps ~8px per request (bug present).
Switched display to “looks like 1920×1080” (exact 2x integer on this panel) without relaunching DEVONthink: bug persists.
Relaunched DEVONthink while in the integer-scaled mode: bug gone — one-shot narrowing works.
Switched back to fractional 2560×1440 with that same process: still works. The bad state was cleared and hasn’t returned yet.
So: the corrupted layout state survives relaunch under the same scaling mode, but relaunching under a different scale factor resets it. This points to some cached width/layout state tied to the fractional backing scale rather than to preferences (deleting those had no effect earlier). Versions unchanged for a week before onset (both DT 4.3.1 and macOS 26.5.1 installed June 3), so it’s runtime-triggered, not update-triggered. The original trigger is still unknown; I’ll report back if it recurs and I can catch what preceded it.
It might be worth testing it on your native mac monitor just to see.
I’ve not upgraded to 26.5.1 yet because the posts in here made me suspicious, but I’ve noticed that since my last update I now have problems with one of my external monitors not being recognised when I reboot my Mac (on the upside I don’t do that as frequently as I should so it’s an intermittent annoyance). I think Apple has messed something up that was working perfectly fine before
Window managers break because of the resizing issue.
I did reproduce the issue in 15.7.7 in Safe Mode, and was also able to “trigger” the issue when I changed the internal display away from the ‘default’ resolution.
On this particular machine (MBA M1, 15.7.7, DT 4.3.1) I do not use an external monitor.
When I first started to test on this machine, it did NOT have this resizing issue.
To trigger it, all I did was go into ‘Display’, and change the resolution from ‘Default’ to one size larger:
Afterwards, the resizing issue started happening. I tried changing it back to ‘Default’ to see if it’d reset, however I can’t undo the issue now. I’ve tried restarting DT, rebooting, safe mode, and re-installing DT 4.3.1.
So my experience looks to align with Jack, in that adjusting the resolution/scaling appeared to trigger it, however in my case I can’t undo it now
