WebKit2 needs support for speak selection <rdar://problem/15212005>
Created attachment 234199 [details] patch
Comment on attachment 234199 [details] patch View in context: https://bugs.webkit.org/attachment.cgi?id=234199&action=review > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1371 > + _page->getSelectionOrContentsAsString([self](const String& string, CallbackBase::Error error) { > + if (error != CallbackBase::Error::None) > + return; > + if ([self respondsToSelector:@selector(accessibilitySpeakSelectionSetContent:)]) > + [self accessibilitySpeakSelectionSetContent:string]; > + }); Is there a guarantee we won’t get the callback after self is deallocated? Do we need to retain/release self? > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1372 > + Stray blank line.
(In reply to comment #2) > (From update of attachment 234199 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=234199&action=review > > > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1371 > > + _page->getSelectionOrContentsAsString([self](const String& string, CallbackBase::Error error) { > > + if (error != CallbackBase::Error::None) > > + return; > > + if ([self respondsToSelector:@selector(accessibilitySpeakSelectionSetContent:)]) > > + [self accessibilitySpeakSelectionSetContent:string]; > > + }); > > Is there a guarantee we won’t get the callback after self is deallocated? Do we need to retain/release self? This is basically what define: does as well, so if that case is safe so will this one. Maybe someone else is able to speak to whether the connection callback blocks are torn down safely when WKContentView goes away... > > > Source/WebKit2/UIProcess/ios/WKContentViewInteraction.mm:1372 > > + > > Stray blank line. Thanks!
http://trac.webkit.org/changeset/170670