| Summary: | Update UIKit when a cut causes a selection change | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Megan Gardner <megan_gardner> | ||||
| Component: | New Bugs | Assignee: | Megan Gardner <megan_gardner> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | bdakin, commit-queue, darin, thorton, wenson_hsieh | ||||
| Priority: | P2 | Keywords: | InRadar | ||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Attachments: |
|
||||||
|
Description
Megan Gardner
2019-04-17 19:02:17 PDT
Created attachment 367711 [details]
Patch
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. |