| Summary: | When a node is removed and that changes selection, we don't notify editor client, and don't fire selectionchange event | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
| Component: | HTML Editing | Assignee: | Alexey Proskuryakov <ap> | ||||
| Status: | ASSIGNED --- | ||||||
| Severity: | Normal | CC: | darin, enrica, rniwa | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 130727 | ||||||
| Attachments: |
|
||||||
|
Description
Alexey Proskuryakov
2014-03-25 15:26:37 PDT
Created attachment 227855 [details]
WIP patch
Attaching a WIP patch. There are still many big issues that may make this impractical for now:
- The patch causes multiple crashes in editing code.
- It only fixes notifications when a removed node contains one of the endpoints, not when a node is removed in the middle of selection.
- It doesn't fix anything when a node is added in the middle of selection.
- It almost certainly doesn't fix anything when text content of nodes is manipulated.
- I haven't even tested what IE does in any of these cases. Maybe it only fires selectionchange event when selecting manually?
One way or another, it's certainly a problem that we don't cleanly track selection and composition changes in WebCore.
Tested, and IE 11 is pretty bad about dispatching selectionchange for programmatic changes. I got the event when removing a contenteditable div with a range selection inside, but not when removing nodes from a selection. But we need to track DOM changes somehow to stay in sync with input methods. |