Update UIKIt when a cut causes a selection change
Created attachment 367711 [details] Patch
<rdar://problem/36311563>
This looks reasonable! A couple of brief comments: - I think we want the same logic in -pasteForWebView:. There's the reverse of this bug, where if a user (1) copies something, (2) makes a ranged selection, and then (3) pastes, one would expect the undo/redo buttons to show up, but the copy/paste/cut buttons are still there, probably because we don't tell UIKit that the selection changes. I *think* this would also be fixed by applying your fix to the paste case. But if you prefer, we can do this as a followup. - I believe writing an API test for this shouldn't be *too* bad. I've recently written some tests in KeyboardInputTestsIOS.mm that focus editable fields and check the state of UIBarButtonItemGroups. You might be able to use these tests as a template.
After several hours of trying, a test has been determined to be unfeasible. I'll fix the copy bug in a followup.
Comment on attachment 367711 [details] Patch Clearing flags on attachment: 367711 Committed r244438: <https://trac.webkit.org/changeset/244438>
All reviewed patches have been landed. Closing bug.
What about when the webpage itself calls execCommand("Cut")? Do we eventually need a different solution to make sure that case is also correctly handled?
(In reply to Darin Adler from comment #7) > What about when the webpage itself calls execCommand("Cut")? Do we > eventually need a different solution to make sure that case is also > correctly handled? Yes, I think we need a different solution for that to work (which may obviate the need for this change). In fact, there's a FIXME for it elsewhere in this file: (WKContentViewInteraction.mm:5656) // FIXME: We need to figure out what to do if the selection is changed by Javascript. We may, for example, want to consider having UIKit re-validate its input assistant items after executing an editing command.