RESOLVED FIXED197047
Update UIKit when a cut causes a selection change 
https://bugs.webkit.org/show_bug.cgi?id=197047
Summary Update UIKit when a cut causes a selection change
Megan Gardner
Reported 2019-04-17 19:02:17 PDT
Update UIKIt when a cut causes a selection change
Attachments
Patch (1.43 KB, patch)
2019-04-17 19:05 PDT, Megan Gardner 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Megan Gardner
Comment 1 2019-04-17 19:05:28 PDT
Created attachment 367711 [details] Patch
Megan Gardner
Comment 2 2019-04-17 19:14:33 PDT
<rdar://problem/36311563>
Wenson Hsieh
Comment 3 2019-04-17 19:38:41 PDT
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.
Megan Gardner
Comment 4 2019-04-18 14:26:48 PDT
After several hours of trying, a test has been determined to be unfeasible. I'll fix the copy bug in a followup.
WebKit Commit Bot
Comment 5 2019-04-18 14:57:53 PDT
Comment on attachment 367711 [details] Patch Clearing flags on attachment: 367711 Committed r244438: <https://trac.webkit.org/changeset/244438>
WebKit Commit Bot
Comment 6 2019-04-18 14:57:55 PDT
All reviewed patches have been landed. Closing bug.
Darin Adler
Comment 7 2019-04-19 14:01:55 PDT
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?
Wenson Hsieh
Comment 8 2019-04-19 20:06:55 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.