Summary: | Can't insert text between non-editable SPAN inside a contenteditable DIV | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Robbie Paplin <rpaplin> | ||||
Component: | HTML Editing | Assignee: | Enrica Casucci <enrica> | ||||
Status: | RESOLVED DUPLICATE | ||||||
Severity: | Normal | CC: | enrica, jparent, michael.vm, rniwa, rpaplin, webkit | ||||
Priority: | P2 | Keywords: | InRadar | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | All | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Robbie Paplin
2008-08-07 16:55:00 PDT
Created attachment 22702 [details]
Test case that shows you can't place caret between non-editable SPAN elements in a contenteditable DIV
This bug might be related to the bug 19698, which says we can't add text before or after span with contenteditable="false" when it is the only child node in a div with contenteditable="true". I have been playing around with this bug for the last few days. This is my first WebKit endeavor so please forgive my ignorance :p. Sorry if I'm too verbose here. The selection/caret has to be linked to a text node of the editable parent (otherwise where are the characters gonna go when you type?). If we have two adjacent non-editable nodes inside an editable parent, then it is impossible for text to be inserted between the nodes unless a text node exists there first. The solution it seems, would be to have WebKit insert empty text nodes in these places. I tried simulating this with JavaScript, but WebKit skips over empty nodes. I have isolated the code that does this and have managed to fix the problem: When you move the caret with the right arrow key, WebKit calls Position::isCandidate on each node after the current position until it returns true. isCandidate will fail on non-editable nodes and empty text nodes, causing the caret to skip over them. You can make empty text nodes valid candidates by ensuring Position::inRenderedText() returns true: bool Position::inRenderedText() const { ... return true; } Note: this should not blindly return true. There needs to be additional logic here. Now that the caret can move inside empty text nodes, we can stop <br/> tags from getting (annoyingly) inserted whenever a text node is removed. void DeleteSelectionCommand::doApply() { ... RefPtr<Node> placeholder = m_needPlaceholder ? document()->createTextNode("") : 0; ... } Note that these fixes do not solve the problem or make the above testcase pass. WebKit needs to insert empty text nodes between the non-editable nodes. I have not yet figured out how to do this without using js. This bug is the same as https://bugs.webkit.org/show_bug.cgi?id=31750. I posted a patch last week and I'm waiting for it to be reviewed. Committed revision 51522. This was the same as https://bugs.webkit.org/show_bug.cgi?id=31750 *** This bug has been marked as a duplicate of bug 31750 *** |