Stealing the firstResponder? about mtstatusbaroverlay HOT 4 OPEN

Are you still experiencing this issue? I can't really reproduce it, maybe it's gone since then.

from mtstatusbaroverlay.

Actually the bug persists, it happens during the status show / hide animations. not only keys events are eaten but most of the touch events are too. stealing the firstResponder seems to be the right title for this issue :(

will test adding UIViewAnimationOptionAllowUserInteraction to the animation options and get back here with the results of my experiements :)

from mtstatusbaroverlay.

I'm having this issue too - I couldn't figure things out until I finally contacted Apple support and they suggested I look for places where my key window is being taken over by another window -- MTStatusBarOverlay is a UIWindow class, so I'm guessing if you show a text input in your original key window, launch another window and make it key - UIResponder will now not work for your previous window unless you reset it to key ... does that make sense?

I should also note that I have not been able to reproduce this issue -- I just have hundreds of users emailing me about the problem.

from mtstatusbaroverlay.

I've been hitting this issue too. I found that whenever I can't type, the status bar overlay window object have become the key window.

(lldb) po [[UIApplication sharedApplication] keyWindow]
$0 = 0x13057ca0 <MTStatusBarOverlay: 0x13057ca0; baseClass = UIWindow; frame = (0 0; 320 20); alpha = 0; layer = <UIWindowLayer: 0x13053da0>>

My solution is to add the following code to app delegate. This way whenever the keyboard is shown the main window is forced to be the key window.

[[NSNotificationCenter defaultCenter] addObserverForName:UIKeyboardWillShowNotification object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification *note) {

    [self.window makeKeyAndVisible];
}];

However, I'm not sure if this would cause other side effects.

from mtstatusbaroverlay.