Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The inputBarAccessoryView is shown along with the UIAlertController, when presented as .actionSheet. #235

Open
chauhan130 opened this issue Jul 28, 2022 · 8 comments
Labels

Comments

@chauhan130
Copy link

Describe the bug
The inputBarAccessoryView is shown along with the UIAlertController, when presented as .actionSheet, works fine for .alert.

To Reproduce
Steps/code to reproduce the behavior:

  1. Open up the example project from MessageKit.
  2. Go to Advanced Example.
  3. Tap on the InputBarAccessoryView's text view to open the keyboard.
  4. When the keyboard is open, tap on the camera icon.

Expected behavior
The keyboard is hidden and the action sheet is presented.

Screenshots

Environment

  • What version of InputBarAccessoryView are you using? 5.4.0
  • What version of iOS are you running on? - iOS 16.0 Beta
  • What version of Swift are you running on? - Swift 5.7
  • What device(s) are you testing on? Are these simulators? - Yes, the iOS simulator for iPhone 13 Pro.
  • Is the issue you're experiencing reproducible in the example app? - The example app from the MessageKit, yes.

Additional context
Add any other context about the problem here.
The issue happens with iOS 16 only. Works fine with the latest iOS 15.

@IAmConorNolan
Copy link

Experiencing this issue too. Did you find any workaround?

@chauhan130
Copy link
Author

@IAmConorNolan, as a temporary workaround, before presenting the alert controller, I do view.endEditing(true), also overrode canBecomeFirstResponderof the viewController and return true only if the current view controller is at the top, like there is no any view controller presented and the in the navigation stack, it is the front most view controller.

@ekazaev
Copy link

ekazaev commented Sep 15, 2022

@IAmConorNolan @chauhan130 Experiencing the same issue. Also the inputAccessoryView appears slower than the animation of the view controller itself. Is it like completely broken in IOS 16?

@IAmConorNolan
Copy link

@ekazaev +1, I'm also experiencing this same lag when transitioning to a view controller showing the inputBarAccessoryView.

@nathantannar4
Copy link
Owner

I think this is an issue MessageKit would have to address. InputBarAccessoryView doesnt track the UIViewController its attached to.

MessagesViewController should probably not be the first responder if its presenting another UIViewController.

As a workaround, you could override its canBecomeFirstResponder and ensure you resignFirstResponder before presenting

@JCsplash
Copy link

Having the same issue. @nathantannar4 is there a more robust fix now or should we still use the workarounds?

@JCsplash
Copy link

JCsplash commented Mar 19, 2023

Seems like iOS 16's deprecating of UIRemoteKeyboardWindow is causing this issue. The code below works great. presentedViewController covers UIAlertController as well as any UIViewController with modalPresentationStyle that's not full screen. Hope this helps anyone else with this issue.

    override var canBecomeFirstResponder: Bool{
        if #available(iOS 16, *) {
            // UIRemoteKeyboardWindow was deprecated in iOS 16 and caused new behavior.
            // Fixes bug where inputAccessoryView displays above actionsheet or panel.
            print("canBecomeFirstResponder: \(!isInputBarHidden && presentedViewController == nil)")
            return preIOS16CanBecomeFirstResponderFlag && presentedViewController == nil
        }
        else {
            return preIOS16CanBecomeFirstResponderFlag
        }
    }

@gerchicov-vg
Copy link

@JCsplash what if I don't own this view controller (inner ads view controllers)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants