[Webkit-unassigned] [Bug 61594] REGRESSION: Hitting enter in the middle of this span causes the cursor to go to the end of the span

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Jun 7 23:17:59 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=61594





--- Comment #19 from Ryosuke Niwa <rniwa at webkit.org>  2011-06-07 23:17:59 PST ---
(In reply to comment #18)
> In IndentOutdentCommand::outdentParagraph(), the code that finds enclosingBlockFlow looks like this: enclosingBlock(visibleStartOfParagraph.deepEquivalent().deprecatedNode()). Then I make a Position from enclosingBlockFlow and pass it to splitTree.

We should be calling containerNode instead of deprecatedNode there.  Because if we're before or after a block, the block isn't enclosing the position at all.  If something goes wrong with that change, then we'd have to fix that bug.

Once you do that, the change is straight-forward.  You'd just need to split the tree at the beginning of this block.

> In ReplaceSelectionCommand::insertAsListItems(), there used to be code that called deprecatedNode() to split the children, but my new code seems to work fine calling containerNode()/offsetInContainer instead. Is that one okay? I think ReplaceSelectionCommand::doApply() and InsertParagraphSeparatorCommand::doApply() are okay as-is as well. Let me know if you disagree.

That sounds like a reasonable change.

> So I wanted to check about the right way to move forward. I think it is:
> 1. File dependent bugs to not use deprecatedNode() in the places I listed above. Are there some existing refactoring patches I can look at to see examples of how this is usually done?

You can see blockers on https://bugs.webkit.org/show_bug.cgi?id=52099 that have been resolved.

> 2. File dependent bugs on the refactoring bugs above to add test cases.

That sounds great!

> Is that right? Or is there some simpler way to do things? Maybe we could add more tests to the codepaths that use deprecatedNode in this patch, and if they prove to be consistent, do some smaller patch-up?

That sounds like a very reasonable approach.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list