Repository navigation
Fixes accessibility issue that bridge fails to clean up FlutterScrollableSemanticsObject - #28495
Conversation
…ableSemanticsObject
c2ebb0d to
f1489f6
Compare
| - (void)willRemoveFromAccessibilityBridge { | ||
| [self removeFromSuperview]; | ||
| } | ||
|
|
There was a problem hiding this comment.
removeFromSuperview is called in the dealloc of the FlutterScrollableSemanticsObject, are these objects leaking, that's why they aren't getting removed from the superview? If so we should fix the leak instead.
There was a problem hiding this comment.
it seems like the superview will hold a reference on this object. The object was never dealloc, so it just keeps adding more UIScrollable :D
There was a problem hiding this comment.
Makes sense, I think we should investigate what I've suggested in my last review before accepting this change.
gaaclarke
left a comment
There was a problem hiding this comment.
Alternatively, instead of making FlutterScrollableSemanticsObject subclass UIScrollView, it could have a UIScrollView. That way when the FlutterScrollableSemanticsObject is deleted, it can remove the UIScrollView from its superview (thus breaking the cycle).
That would be preferable because, while the solution you are proposing will work, it is much more costly to maintain than if everything just works with standard object memory management.
|
existing test should cover the refactoring PTAL @gaaclarke |
gaaclarke
left a comment
There was a problem hiding this comment.
Awesome, LGTM with the caveat that you've tested it locally too. Despite our work to improve the testing on this code it still makes me a bit nervous to change it.
I have tested it locally. I think this is one step toward the right direction, and we just need to watch out for regression... |
…erScrollableSemanticsObject (flutter-team-archive/engine#28495)
| - (instancetype)initWithSemanticsObject:(SemanticsObject*)semanticsObject { | ||
| self = [super initWithFrame:CGRectZero]; | ||
| if (self) { | ||
| _semanticsObject = semanticsObject; |
There was a problem hiding this comment.
I believe we're missing a retain here, which is the cause of a crash noted in flutter/flutter#92853
There was a problem hiding this comment.
It was not that we're missing a retain, but that we're missing niling this out when the parent object is deallocated.
| uid:(int32_t)uid { | ||
| self = [super initWithBridge:bridge uid:uid]; | ||
| if (self) { | ||
| _semanticsObject = [semanticsObject retain]; |
|
these commits have been merged in flutter 2.8 ,but this crash is also exist. stack belows: flutter::AccessibilityBridge::GetOrCreateObject(int, std::__1::unordered_map<int, flutter::SemanticsNode, std::__1::hash, std::__1::equal_to, std::__1::allocator<std::__1::pair<int const, flutter::SemanticsNode> > >&) (in Flutter) (accessibility_bridge.mm:303) |
|
@zjrwdl if you are still seeing the same crash it may be a different cause, can you file a new issue with repro steps? |
fixes flutter/flutter#89613
Pre-launch Checklist
writing and running engine tests.
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.