ios accessibility: started ignoring route changes when presenting modal view controllers

[gaaclarke]

Relevant issue flutter/flutter#56850

This PR ignores route change notifications in cases where a modal view controller is being presented.

Since there doesn't seem to be a reliable way to query if a view controller is animating in a modal view controller we had to add an extra property to FlutterViewController to keep track of that. Now when it is presenting we are mum about route changes since it would only serve to confuse.

[gaaclarke]

Nobody moved on this PR so I'm going to change it to incorporate it in my fix for the related issue.

[gaaclarke]

@goderbauer @GaryQian friendly ping on review

[gaaclarke]

@goderbauer @GaryQian less friendly ping for review ;)

[goderbauer]

Why run the notification through the delegate as well?

[gaaclarke]

For testing. We can't test that someone has called UIAccessibilityPostNotification so the delegate allows us to do dependency injection.

[goderbauer]

That makes sense. Thanks for the explanation :)

[gaaclarke]

@jmagman @goderbauer has requested someone with more objc experience to do a review

[goderbauer]

Thee a11y stuff looks good. Can you please have somebody with ObjC expertise take a look at this as well?

[jmagman]

Can the model view controller itself be a FlutterViewController? Should it itself handle being presented modally with viewWillAppear/isBeingPresented? Maybe add-to-app?

[jmagman]

This function name sounds like it would return the view.nextResponder if the viewcontroller is a FlutterViewController, not that it would necessarily walk up the responder chain.

Maybe GetNextFlutterResponder?

FlutterViewController*_Nullable GetNextFlutterResponder(id<UIResponder> view) {
  id nextResponder = [view nextResponder];
  if ([nextResponder isKindOfClass:[FlutterViewController class]]) {
    return nextResponder;
  } 
  if ([nextResponder conformsToProtocol:@protocol(UIResponder)) {
    return GetFlutterViewControllerForView(nextResponder);
  }
  return nil;
}

[gaaclarke]

If i named it that, the name would match better with the implementation details, but it would be less clear at the call site what I was doing. If you ignore the implementation details this function does what the function name suggests. It's an artifact of not having a good way to do this in UIKit. If wanted to tear things up more I'd stop tracking a UIView in the bridge and actually trace a FlutterViewController so we wouldn't need this. I'll add the nullable annotation and add a comment to explain the implementation.

[jmagman]

I don't think the UL is necessary any more (there was a time where you'd get a compilation warning, but they fixed that a few years ago).

[gaaclarke]

I just removed it to see what happens and it still creates an error.

[jmagman]

Should retain and release this instead of letting the autorelease pool handle it (usually -autorelease if you're returning a value from a method, say, not if you actually are in control of the scope). But yeah it's a test so whatever.

[gaaclarke]

In ObjC++ the rules are a bit different because of RAII. If I didn't put an autorelease here I should have a RAII wrapper around the pointer... I tried to get this file compiling with ARC but there is a hangup supporting that. Hopefully we can migrate it.

[jmagman]

This is my own UIViewController ignorance showing, but what happens if you present two in a row? I'm guessing one animation finishes before the next one starts?

[gaaclarke]

Presenting one while the other is animating? No idea. I would actually expect the first animation to be cancelled.

[jmagman]

Same.

[gaaclarke]

ack

[gaaclarke]

Can the model view controller itself be a FlutterViewController? Should it itself handle being presented modally with viewWillAppear/isBeingPresented? Maybe add-to-app?

There is nothing stopping it from being a FlutterViewController. If it was one, I would expect ios_delegate_->IsFlutterViewControllerPresentingModalViewController(view_) to return false and the notification would get sent as normal from the accessibility_bridge of the modal view.

There may be a difference when using a FlutterViewController with a shared engine versus its own engine. With a shared engine I could see there being some timing issues related to creating the accessibility bridge.

[xster]

Looks like platformviewios right above it has a FlutterViewController anyway. We can just refactor this private constructor to take a FVC if needed.

[gaaclarke]

Yea, i can look into it. i'll split it into a different PR to keep the bug fix and the refactor separate.

[xster]

SG

[gaaclarke]

#18800

[gaaclarke]

landing on purple Mac Engine Drone has purpled out but isn't being recognized.