TotalFinder focussed tab unresponsive until tabs switched

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.

I’m running TotalFinder 1.6.25 on OS X 10.10.3.

Any thoughts appreciated.
Mark.

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.

Hi Darwin,

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?

Please install the new beta and you should be no longer experiencing that problem:
http://totalfinder.binaryage.com/beta-changes#1.6.27

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.

This sounds great. I’m running 1.6.27 now and will observe. No reported problems on the most recent wake from sleep.

Thanks for the swift turnaround here. Very impressive.

Hello again. Sadly 1.6.27 hasn’t solved the issue for me. I’m still lacking mouse control (though keyboard does get through.)

Mark.

Ah, so the bug is somewhere else and I will have to come up with another theory why is this happening… :disappointed:

I think more fruitful will be me trying to reproduce the issue by trying to sleep/wake computer multiple times. Stay tuned.