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

View Not Cleared With Multiple BlockAlertView's Triggered by UIButton #24

Closed
nickalto opened this Issue May 8, 2012 · 5 comments

Comments

Projects
None yet
5 participants

nickalto commented May 8, 2012

Overview

Triggering a BlockAlertView via UIButton before the current BlockAlertView has finished it's dismissal animation causes the BlockAlertView to stay in the view, not allowing the user to dismiss it. The next BlockAlertView executes [alert show] before the previous BlockAlertView has time to execute it's completion block which clears the view.

Steps to Reproduce

  • Trigger a BlockAlertView from the "Show Alert" UIButton
  • Dismiss this BlockAlertView with "Cancel" or "Kill"
  • Quickly tap the "Show Alert" UIButton again before the Alert has completed it's dismissal animation
    • (Much easier to reproduce on a physical device, slightly more difficult to reproduce on the emulator)
  • This should cause the next BlockAlertView to be shown in the view, with no way of dismissing it.

This has been tested with the Trunk as well as BinaryDev's ARC-compatible branch. To be thorough I included a stack trace below.

0   BlockAlertsDemo      0x0000859e -[BlockAlertView show] + 6062
1   BlockAlertsDemo      0x000024f9 -[BlockAlertsDemoViewController showAlert:] + 489
2   CoreFoundation       0x013dde99 -[NSObject performSelector:withObject:withObject:] + 73
3   UIKit                0x0002914e -[UIApplication sendAction:to:from:forEvent:] + 96
4   UIKit                0x000290e6 -[UIApplication sendAction:toTarget:fromSender:forEvent:] + 61
5   UIKit                0x000cfade -[UIControl sendAction:to:forEvent:] + 66
6   UIKit                0x000cffa7 -[UIControl(Internal) _sendActionsForEvents:withEvent:] + 503
7   UIKit                0x000cf266 -[UIControl touchesEnded:withEvent:] + 549
8   UIKit                0x0004e3c0 -[UIWindow _sendTouchesForEvent:] + 513
9   UIKit                0x0004e5e6 -[UIWindow sendEvent:] + 273
10  UIKit                0x00034dc4 -[UIApplication sendEvent:] + 464
11  UIKit                0x00028634 _UIApplicationHandleEvent + 8196
12  GraphicsServices     0x012c6ef5 PurpleEventCallback + 1274
13  CoreFoundation       0x013b0195 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 53
14  CoreFoundation       0x01314ff2 __CFRunLoopDoSource1 + 146
15  CoreFoundation       0x013138da __CFRunLoopRun + 2218
16  CoreFoundation       0x01312d84 CFRunLoopRunSpecific + 212
17  CoreFoundation       0x01312c9b CFRunLoopRunInMode + 123
18  GraphicsServices     0x012c57d8 GSEventRunModal + 190
19  GraphicsServices     0x012c588a GSEventRun + 103
20  UIKit                0x00026626 UIApplicationMain + 1163
21  BlockAlertsDemo      0x00001de2 main + 130
22  BlockAlertsDemo      0x00001d55 start + 53

nickalto commented May 8, 2012

I forked the trunk and came up with a possible solution (https://github.com/nickalto/BlockAlertsAnd-ActionSheets) that makes each BlockAlertView atomic, so you can only trigger another alert after the current one has completely finished animating and executing it's completion block. The only draw back is that it doesn't allow for one BlockAlertView to trigger another BlockAlertView. A queue could be implemented to maintain this functionality and atomicity. I would love feedback to see if this warrants a pull request or if anyone has suggestions on better fixes.

Did anyone came up with any solution for this issue?

Sometimes alert is not dismissed when show it several times in the same viewcontroller. I can interact with controls behind alert which can't be dismissed.

giffnyc commented Apr 10, 2013

I was just wrestling with this - I don't have the time to work on a fix, but hope to come back to it a bit later. Thought I'd note my observation here....

The BlockBackground is the object that is made a key window. This is a singleton object and it holds onto the original keywindow, so that when it goes away, it can yield back the original window.

It holds any sheets as subviews - so when several are added, the singleton object has a hierarchy of views.
At some point, the prior views are removed from the subview and, I think, the intent is to make the next view down active. In the removeView method of the BlockBackground object, when the topmost view is removed, a check is made to see if there is another view in the hierarchy, and this view's userInteractionEnabled is set to YES.

I think there is something wrong with the hierarchy at this point that prevents the view from having its property set, and hence we get views we can see, but who's dismiss button we can't press.

I have been peeking in the debugger at the view hierarchy at this point using the handy-dandy 'po [view recursiveDescription]' but I've run out of time to fuss with it.

@barrettj barrettj closed this in 09d3b71 Apr 12, 2013

Collaborator

barrettj commented Apr 12, 2013

Try the commit I just pushed, I think that should fix this issue.

@ghost ghost assigned barrettj Apr 12, 2013

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