When the caret is in front of a block element (e.g. ,<div>), the "delete" key does nothing. In the attached testcase, place the caret immediately after "foo" and hit "delete". Notice that nothing happens. Expected: the "bar" should move into the line with "foo" so that it would read "foobar". This is probably a regression form bug 157546.
Created attachment 305404 [details] [diff] [review] possible fix This fixes the problem, and also changes the behavior of deleting cross-block selections (in a way that IMO is positive). This is potentially a bit scary (to me, anyway), so I'm not sure if we want to take it into 1.9 at such a late stage.
Comment on attachment 305404 [details] [diff] [review] possible fix Looks OK to me but I'm not the right reviewer for this.
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee: nobody → uriber
Peterv, can you please do the review here?
Whiteboard: [needs review peterv]
Comment on attachment 305404 [details] [diff] [review] possible fix AFAICT leftParent and rightParent can be be in unrelated subtrees and JoinBlocks expects either one to be contained by the other or for them to be siblings. It's all hairy code, so I might be mistaken :-/. If I'm not, would it make sense to check first that leftParent and rightParent are either siblings or that one contains the other? I *think* that should still fix the bug.
We're leaving this on the blocking list, with the plan that we back out the checkin that caused it if this patch isn't ready (which probably means backing it out shortly, actually, since the backout may have risk).
Same for bug 419406.
Created attachment 315612 [details] [diff] [review] v2 This fixes the bug too, and makes me slightly less nervous.
This bug was fixed by backout of bug 157546.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
verified fixed using the testcase and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050621 Firefox/3.0pre --> Verified fixed
Status: RESOLVED → VERIFIED
uhm, I can't figure out how to reopen this bug this bug actually still happens in FF 3.5.1. in addition, the unit test case for this bug is not working properly (it still passes, but if you open the test case attached here and try it manually, it is broken) a patch to fix this bug and the unit test is attached to Bug 502259
Confirm that, this is still broken in FF3.5.1.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
this is fixed along with bug 502259 (in FF 3.5.4)
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago → 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.