Doesn't play well with UIMenuController under iOS 5.1(b)

[bzotto]

Heads-up. Under iOS 5.1b, once the HUD has appeared and then disappeared, invocations elsewhere in the UI of UIMenuController will fail (ie the menu will simply not appear), both in custom views but also in system-standard text views.

It's something to do with the interactions in window ordering, though I'm not sure whether it's a beta-only bug that Apple's introduced, or whether this is going to be a production problem. I'm not well enough versed in the UIWindow stuff to understand what's happening exactly, but possibly the UIMenuController lives on its own window and that's getting shuffled behind when the HUD dismisses?

Opening another modal view controller (e.g. the mail compose controller, or any custom form sheet, etc) "clears" the condition and the menu will function again.

Workaround: If I turn the HUD into a UIView subclass (rather than UIWindow) and simply add it as a subview to my current known window, I find it no longer exhibits this interaction.

[samvermette]

Thanks @bzotto, I will look into this shortly.

[samvermette]

I'm currently away from home and don't have access to the 5.1 SDK, but you can start by checking the value of previousKeyWindow at the end of the show method and then in the dismiss method. My guess would be that your UIMenuController instance isn't assigned to it (maybe because of its windowLevel property, haven't looked at the 5.1 doc yet), so it's not made the key window again upon the HUD's dismiss.

[bzotto]

Hey Sam,
Thanks for the comment. It looks like this issue doesn't appear with your
stock SVProgressHUD. I've been playing with a modified fork from BarrettJ,
and the HUD's UIWindow seems to linger on in the window list after it
dismisses there, which looks suspicious. I'll keep poking at it and let him
(and you) know if I root-cause it.

Thanks, sorry for the confusion.

Ben

On Sun, Dec 11, 2011 at 3:49 AM, Sam Vermette <
reply@reply.github.com

wrote:

I'm currently away from home and don't have access to the 5.1 SDK, but you
can start by checking the value of previousKeyWindow at the end of the
show method and then in the dismiss method. My guess would be that your
UIMenuController instance isn't assigned to it (maybe because of its
windowLevel property, haven't looked at the 5.1 doc yet), so it's not made
the key window again upon the HUD's dismiss.

---

Reply to this email directly or view it on GitHub:
#35 (comment)

Cocoa Box -- http://www.cocoabox.com
Makers of fine applications for iPad and iPhone
Follow us on Twitter at http://twitter.com/cocoabox

[bzotto]

OK, nevermind. Not only was this not an issue with core SVProgressHUD, it was not an issue with Barrett's fork, either. I'd introduced a subtle behavior change in the window search when I retrofitted it for iOS 3.x compatibility that only caused a problem on 5.1b, weirly. This one was all me. Sorry guys, and thanks.

[samvermette]

Hah, ok. Thanks for the follow-up!