Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Slate freezes on interaction #140

Open
minimal opened this Issue Oct 29, 2012 · 37 comments

Comments

Projects
None yet

minimal commented Oct 29, 2012

Sometimes slate will freeze for 5 to 20 seconds anytime I try to
interact with it. E.g. clicking on the icon will show the spinner for
a number of seconds before showing the menus. Or a shortcut will not
execute for some time after it is pressed. Actions will appear not to
work and then they will all happen in sequence after a delay.

This problem occurs every so often and once it has started it does not
end until after rebooting the OS or after a number of hours/days
without using slate. Restarting slate does not fix it.

It has occurred on all version I have tried (1.06 and 1.0.12).

Is there anything I can do to help debug it?

Chris

@ghost ghost assigned jigish Oct 29, 2012

Owner

jigish commented Oct 29, 2012

Hey Chris, yah there is a bunch of information that could help. If you can, I need:

  1. OS version
  2. .slate file
  3. usage patterns (e.g. I use window hints a lot but I don't use the chain binding all that much)
  4. what you are usually doing when it freezes
  5. any other applications you use that could potentially be interacting with things slate uses (other window managers or key binders and such).

minimal commented Oct 30, 2012

Hi Jigish

OS X 10.7.4
my slate is at
https://github.com/minimal/dotfiles/blob/d590c70f70a91b26f63385eed68c6200e9f46e81/default.slate

I mainly use it for setting multi window layouts of chrome, iterm and
emacs across two monitors. (at bottom of slate file - layout dev)

Not usually doing anything in particular, just at one point it starts
pausing whenever I tried to use it or click on the icon.

I do use quicksilver to focus apps with hotkeys.

Slate works very well when that problem isn't occurring.

Cheers

Chris

badders commented Oct 31, 2012

Just want to confirm this bug, am getting it myself. Fully updated mountain lion, on the new macbook pro. This is the one with the retina display running at the 'best for retina' display resolution.

.slate is pretty simple, all i have is it setup to put windows over half screen:

config defaultToCurrentScreen true
config nudgePercentOf screenSize
config resizePercentOf screenSize

alias left-half move screenOriginX;screenOriginY screenSizeX/2;screenSizeY
alias right-half move screenOriginX+screenSizeX/2;screenOriginY screenSizeX/2;screenSizeY

bind right:alt ${right-half}
bind left:alt ${left-half}

Contributor

trishume commented Oct 31, 2012

I have encountered this problem when unplugging and plugging in new monitors on a retina macbook. It occurs infrequently and all the times it has happened restarting slate a few times has fixed it.

philc commented Nov 16, 2012

I see the same thing from time to time with window hints. Anecdotally, it's when an application window is being unresponsive. Jigish, one possible way to see if there's anything to this bug is to create a quick mac app which blocks the UI thread in a busy-wait loop and see if Slate chokes when trying to get the accessibility information for that window.

Owner

jigish commented Nov 17, 2012

interesting. good call Phil. I'll try that and see what happens.

I experienced this too, and @philc clued me in on the reason. I am/was running App Tamer which suspends backgrounded applications (and gives them some time to process events at regular intervals). Slate consistently freezes until all applications have been activated.

Owner

jigish commented Dec 5, 2012

This happened to me too, finally. Skype was not responding and slate crapped out. Temporary fix: force quit applications that are being stupid.

Just thinking about it, I'm guessing that this is because Slate keeps track of applications in the background and when one doesn't respond the Accessibility API craps out like @philc mentioned. I'll try to check it out when I get time.

I am seeing this issue on 10.8.2.

My typical usage pattern

alias center move screenOriginX+screenSizeX/8;screenOriginY+screenSizeY/8 screenSizeX_0.75;screenSizeY_0.75
bind c:ctrl;shift;alt;cmd ${center}

When triggering the position I see no change for ~20 seconds (during which if I mouse over the menu bar icon I see a spinner).

philc commented Jan 3, 2013

@jjlharrison , are any of your apps unresponsive when you see that delay?

@philc Looks like it was the App Tamer issue that @hugowetterberg mentioned.

Still active. OS X 10.8.2, Slate Version 1.0 (1.0.25). Slate was very unresponsive to both key strokes or clicking on the slate icon in the menu bar. Culprit was an unresponsive Skype, resolved by force closing Skype.

mkeeter commented Jun 27, 2013

I'm noticing this on OS X 10.6, Slate 1.0.25

Here's a very easy way to trigger the bug:

  • Run /Applications/Safari.app/Contents/MacOS/Safari in a Terminal
  • In the same terminal, press Ctrl+Z (to suspend the Safari)
  • Try to do something with Slate -- it will hang.

philc commented Jun 27, 2013

I hit this all the time and it's really jarring. Slate should be resilient to apps which are hung or just generally unresponsive.

I was getting this exact same issue. Turns out I had JVisualVM running and it was shown as unresponsive in the Force Quit menu. As soon as I killed it, Slate returned back to it's former glory. Perhaps instead of hanging the app when a background process is not responding, can you error out and show an error to the user?

Is this problem been multiplied because of Mavericks and App Nap?

(the answer to that question is a very much yes)

Wasn't happening to me pre-Mavericks, but I'm running into this issue now.

keith commented Dec 14, 2013

Seeing this unresponsiveness as well. Don't think App Nap has much to do with it since menu bar apps only get put into an App Nap state if the menu bar is hidden, via fullscreen mode or something (I believe)

@keithbsmiley I don't think Slate is being app nap'd but that Slate freezes when other apps are getting nap'd

keith commented Mar 1, 2014

@linkinpark342 gotcha yea that makes more sense. Phoenix does not have this issue thankfully.

zfdang commented Apr 2, 2014

I've experienced the same issue today. even I killed slate and started it again, the problem still exists. not sure what happened

wincent commented Apr 2, 2014

@zfdang In my experience it is always another non-responsive app that blocks Slate. (For me, it's often Chrome Canary, but it could be anything.)

If Slate "freezes", I switch the Activity Monitor, sort by Name, and look for the "(Not Responding)" app and kill it. Slate immediately gets better after that.

There are some apps which always claim to be "Not Responding", but you learn to ignore those (ie. jamfAgent always misreports as not responding).

Just a note for anyone else that runs into this -- also check if you have any applications you've suspended from the shell (C-z) as it amounts to the same thing.

keith commented Jul 22, 2014

There hasn't been a commit on slate since February 2013. I, and seemingly many others, have moved to https://github.com/sdegutis/hydra

We had this same issue in Hydra, but fixed it by using a private API. A cleaner way is probably just to set a timeout on the AX operations.

@jigish You might find this function helpful in implementing this feature, if you're comfortable with using private APIs. Otherwise, this public function might be another way to go.

wincent commented Jul 22, 2014

Nice, @sdegutis. Hydra looks great, but I don't want to port my extensive Slate JS config to another program, so I might take a stab at this myself based on your tip.

@wincent Glad I could help. And thanks.

wincent added a commit to wincent/slate that referenced this issue Jul 22, 2014

Prevent Slate from hanging waiting for unresponsive apps
Make use of a private API to prevent Slate from hanging waiting for
unresponsive apps.

Tested by pausing Google Chrome with a command like `kill -STOP 11019`,
then interacting with Slate (using hot keys to reposition windows). I
observed that there is some lag before the `CGSEventIsAppUnresponsive`
API actually registers the state of the world; it returns `false` at
first, but after about 20 seconds it correctly returns `true`. During
the initial interval, interacting with Slate is laggy; after that, it
becomes snappy.

Resumed Chrome with `kill -CONT 11019`.

Fixes: jigish#140

Thanks to @sdegutis for the tip.

@wincent Is your config located somewhere online?

@janaspage lol cool, glad to be of service, 👍

harizvi commented Jul 25, 2014

Steve, I have already moved to Hydra, but can I avail of this service :-)
I have (copied from somewhere) a cycleCalls function, which rotates a window's size/position amongst the settings. Is there a version of this for Hydra that you are aware of?
// cycles a window from half, 3/4ths, 2/3rds on the right side.
bind( 'right', mCmd, cycleCalls(
toGrid,
[
[0.5, 0, 0.5, 1],
[0.25, 0, 0.75, 1],
[0.34, 0, 0.66, 1]
]
));

// Cycle args for the function, if called repeatedly
// cycleCalls(fn, [ [args1...], [args2...], ... ])
var lastCall = null;
function cycleCalls(fn, argsList) {
var argIndex = 0, identifier = {};
return function () {
if (lastCall !== identifier || ++argIndex >= argsList.length) {
argIndex = 0;
}
lastCall = identifier;
fn.apply(this, argsList[argIndex]);
};
}

@harizvi Can you open an issue in Hydra about this so we don't clutter this issue with unrelated discussion? Thanks!

djl added a commit to djl/slate that referenced this issue Jul 27, 2014

Prevent Slate from hanging waiting for unresponsive apps
Make use of a private API to prevent Slate from hanging waiting for
unresponsive apps.

Tested by pausing Google Chrome with a command like `kill -STOP 11019`,
then interacting with Slate (using hot keys to reposition windows). I
observed that there is some lag before the `CGSEventIsAppUnresponsive`
API actually registers the state of the world; it returns `false` at
first, but after about 20 seconds it correctly returns `true`. During
the initial interval, interacting with Slate is laggy; after that, it
becomes snappy.

Resumed Chrome with `kill -CONT 11019`.

Fixes: jigish#140

Thanks to @sdegutis for the tip.

Like other's have mentioned, I'm having the same issue with Slate freezing intermittently on hung apps. I see that there's a pull request to fix this issue. Don't see any blockers for merging it.

mattr- added a commit to mattr-/slate that referenced this issue Aug 28, 2014

Prevent Slate from hanging waiting for unresponsive apps
Make use of a private API to prevent Slate from hanging waiting for
unresponsive apps.

Tested by pausing Google Chrome with a command like `kill -STOP 11019`,
then interacting with Slate (using hot keys to reposition windows). I
observed that there is some lag before the `CGSEventIsAppUnresponsive`
API actually registers the state of the world; it returns `false` at
first, but after about 20 seconds it correctly returns `true`. During
the initial interval, interacting with Slate is laggy; after that, it
becomes snappy.

Resumed Chrome with `kill -CONT 11019`.

Fixes: jigish#140

Thanks to @sdegutis for the tip.

Why hasn't the fix been merged yet? I still have this issue with OS X 10.10 with slate 1.0.25.

slate.js was great, but the constant lag and freezing was too much.

I've switched to Phoenix because slate is no longer being maintained. Phoenix has all the same functionality (configs are in javascript) but with no speed hiccups. Happy with the move so far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment