# TotalFinder focussed tab unresponsive until tabs switched **URL:** \ **Category:** TotalFinder\ **Created:** [June 2, 2015, 9:51am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804 "2015-06-02T09:51:51Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Mark\_Russell](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/mark_russell/32/1374_2.png) [@Mark\_Russell](https://discuss.binaryage.com/u/Mark_Russell)\ **Post date:** [June 2, 2015, 9:51am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/1 "2015-06-02T09:51:51Z")
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. ---
**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\ **Post date:** [June 2, 2015, 10:16am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/2 "2015-06-02T10:16:55Z")
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. ---
**Author:** ![Mark\_Russell](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/mark_russell/32/1374_2.png) [@Mark\_Russell](https://discuss.binaryage.com/u/Mark_Russell)\ **Post date:** [June 2, 2015, 1:30pm UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/3 "2015-06-02T13:30:36Z")
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? ---
**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\ **Post date:** [June 5, 2015, 7:02am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/4 "2015-06-05T07:02:21Z")
Please install the new beta and you should be no longer experiencing that problem: [http://totalfinder.binaryage.com/beta-changes#1.6.27](http://totalfinder.binaryage.com/beta-changes#1.6.27) I have implemented a different mechanism under Yosemite. It was needed to fix this issue: > [@\[RESOLVED\] File Moving/Copying UI BUG in 1.6.2x betas? (must to top area/outside of tab?)](http://discuss.binaryage.com/t/resolved-file-moving-copying-ui-bug-in-1-6-2x-betas-must-to-top-area-outside-of-tab/3810): > > Before you read the bottom, more regression: In 1.6.17 I can move/copy files INTO (inside) the tab area and get move/copy focus even with “narrow tabs”. In 1.6.23(? where I first noticed) I must move the dragged files to the TOP EDGE of the tab (even outside the bounds of the tab!) or I do not get focus, feedback UI, or ability to move/copy. For an uninitiated user, it looks like below. Why did everything move 10-15 pixels UP for dragging/moving? I’ve regressed this in 1.6.17: I can MOVE f… 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. ---
**Author:** ![Mark\_Russell](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/mark_russell/32/1374_2.png) [@Mark\_Russell](https://discuss.binaryage.com/u/Mark_Russell)\ **Post date:** [June 5, 2015, 11:22am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/5 "2015-06-05T11:22:50Z")
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. ---
**Author:** ![Mark\_Russell](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/mark_russell/32/1374_2.png) [@Mark\_Russell](https://discuss.binaryage.com/u/Mark_Russell)\ **Post date:** [June 8, 2015, 9:57am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/6 "2015-06-08T09:57:34Z")
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. ---
**Author:** ![darwin](https://discuss.binaryage.com/user_avatar/discuss.binaryage.com/darwin/32/2275_2.png) [@darwin](https://discuss.binaryage.com/u/darwin)\ **Post date:** [June 8, 2015, 11:06am UTC](https://discuss.binaryage.com/t/totalfinder-focussed-tab-unresponsive-until-tabs-switched/3804/7 "2015-06-08T11:06:04Z")
Ah, so the bug is somewhere else and I will have to come up with another theory why is this happening… 😞 I think more fruitful will be me trying to reproduce the issue by trying to sleep/wake computer multiple times. Stay tuned.