If I return to TotalFinder after a period (including, but not always, sleep) the focussed tab is often unresponsive. Items in that tab can’t be interacted with.
The workaround is simple: I switch to a non-focussed tab and then switch back. After doing that the previously unresponsive tab works as intended.
I’ve been using TotalFinder for a long time and this issue has been happening for months. I’m used to this bug, but it’s bloody annoying, so I thought I’d finally report it. Happy to send logs/investigate if need be. This is a long-standing bug that I think used also to occur in Yosemite.
One possible theory if only mouse interaction is affected, but keyboard works as expected:
Technically the main trick of TotalFinder is that it overlays Finder windows on top of TotalFinder’s background window with tabs. It uses windowing API to glue two or more windows together. Unfortunately sometimes I need mouse clicks to go through Finder windows to be received by background TotalFinder window. For example this is needed for masking out Finder window edges so resizing is handled by background window, not glued Finder window itself.
So I need to “punch holes” in Finder window. I do it by defining tracking areas over Finder window, which when entered by mouse make Finder window completely transparent to mouse clicks.
This works pretty well, but it looks that Finder window can get into some weird state where it stays transparent to mouse clicks and tracking areas do not work anymore to re-enable normal behaviour when mouse leaves. Maybe those tracking areas get removed without me knowing.
I will review this whole subsystem again and try to make it more robust. It is pretty hard to track this rare situation down.
Thanks for the response. I see what you’re doing. Is there anything I can test? My TotalFinder tab is non-interactive (“transparent to mouse clicks”) at the moment (after waking from sleep.)
I can report the current behaviour:
Mouse interactions non-functional
Keyboard interactions work (e.g. arrow up/down selects
different files; space activates quick look, etc)
Quick look actually ‘punched through’ and afterwards mouse was re-enabled. (At least I assume it was quick look.)
That last one could be my new workaround.
Could you not throw a fake mouse event at the front tab when the Finder is re-focussed?
I have implemented a different mechanism under Yosemite. It was needed to fix this issue:
The new solution:
Instead of defining tracking areas and keeping them updated, I observe all events coming to Finder windows. And depending on mouse position, I enable or disable Finder’s “mouse transparency”. This approach is more robust, because I don’t keep any state. I always act depending on actual situation and Finder cannot stay stuck in transparent state, because mouse activity will trigger re-evaluation.
