Closed Bug 419217 Opened 14 years ago Closed 12 years ago

Can't forward-delete into block

Categories

(Core :: DOM: Editor, defect, P2)

x86
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: uriber, Assigned: uriber)

References

Details

(Keywords: regression, testcase, Whiteboard: [needs review peterv])

Attachments

(3 files)

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.
Flags: blocking1.9?
Attached file testcase
Bugzilla is playing tricks on me.
Keywords: testcase
Attached patch possible fixSplinter Review
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.
Attachment #305404 - Flags: review?(roc)
Comment on attachment 305404 [details] [diff] [review]
possible fix

Looks OK to me but I'm not the right reviewer for this.
Attachment #305404 - Flags: superreview?(peterv)
Attachment #305404 - Flags: review?(roc)
Attachment #305404 - Flags: review?(peterv)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Flags: tracking1.9+
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.
Attached patch v2Splinter Review
This fixes the bug too, and makes me slightly less nervous.
This bug was fixed by backout of bug 157546.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
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
Attachment #305404 - Flags: superreview?(peterv)
Attachment #305404 - Flags: review?(peterv)
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
Closed: 14 years ago12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.