Correct iOS delegate method prototype #1963
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After the merge of #1946, we've been seeing intermittent failures on two iOS tests:
The errors are both caused when the widget being tested loses focus as a result of another widget being explicitly given focus. In CI conditions, the widget doesn't lose focus as a result of call to give the other widget focus.
I haven't been able to reproduce this problem locally; however, via #1960 I have been able to rule out it being an issue of the event loop not catching up - a longer wait after the focus call doesn't make the test pass; this indicates that the widget is refusing to give up focus.
The willingness of a UITextView widget to give up focus is controlled by its delegate; specifically, the
textViewShouldEndEditing:
selector. This method returnsTrue
if the view is allowed to lose focus.The current implementation decleares this method, but doesn't declare a return type on the delegate method. ObjC only uses the argument prototype for matching, so the delegate was being found; however, the return type wasn't declared, so Rubicon would have been interpreting the
True
value as ac_void_p
before passing to the ObjC runtime. In most cases, this will result in the right answer, but clearly there is an edge case where it could fall through and be interpreted asFalse
.The problem appears to be fixed by explicitly providing a return value of
bool
on the delegate method; but we're not actually doing anything in our custom implementation of the method, and implementation is explicitly described as optional, with a default behavior equivalent to returning YES, so we can simplify our code by removing the method entirely.PR Checklist: