arni2033 Reporter
	Description • 8 years ago

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open url   data:text/html,<div contenteditable>asdf asdf<br>z
2. Click in contenteditable element
3. Press Ctrl+A, then Right key, then type "z"
4. Press Ctrl+A, then Right key, then type "z"
5. Press BackSpace

AR:  "asdf asdf\nzz".  Caret disappears from [contenteditable]. Typing further text has no effect
ER:  "asdf asdf\nzz[caret]"

	Ciprian Muresan [:cmuresan], Ecosystem QA
	Comment 1 • 8 years ago

Narrowed nightly regression window from [2015-03-13, 2015-03-15] (2 days) to [2015-03-13, 2015-03-14] (1 days) (~0 steps left)
Got as far as we can go bisecting nightlies...
Last good revision: 42afc7ef5ccb (2015-03-13)
First bad revision: 38154607d807 (2015-03-14)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=42afc7ef5ccb&tochange=38154607d807

Ehsan, could you take a look and see if this is related to bug 1100966?

	(no longer active)
	Comment 2 • 8 years ago

Redirecting to Masayuki.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 3 • 8 years ago

testcase: https://jsfiddle.net/d_toybox/qv6z2skc/1/
Looks like that pressing ArrowRight key sets selection range to the end of <div>. That's the unexpected behavior. Like Chromium, we should set the selection range at the end of the last text node.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 4 • 8 years ago

Ah, but the actual cause of this is, "Select All" causes setting ranges entire children of the <div>. Chromium sets first child's 0 to the end of the last child. So, looks like this is a compatibility issue of selection.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 5 • 7 years ago

According to https://bugs.chromium.org/p/chromium/issues/detail?id=336821, they think that Chromium's selectAllChildren() is buggy and Selection API spec also defines that it should behave as ours.

So, I think that we should only change the behavior of "Select All" in editor.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 6 • 7 years ago

Hmm, or, perhaps, we should make EditorBase::FindBetterInsertionPoint() HTMLEditor aware because Selection API can set same result as current "Select All".

	Liz Henry (:lizzard Please n-i to RyanVM, jcristau, or pascal)
	Comment 7 • 7 years ago

Too late for a fix for 53, as we are in the last week of the 53 beta cycle.

	Nathan Froyd [:froydnj]
	Comment 8 • 7 years ago

Masayuki, do you think a fix for 54 is feasible?

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 9 • 7 years ago

(In reply to Nathan Froyd [:froydnj] from comment #8)
> Masayuki, do you think a fix for 54 is feasible?

Ah, no. I'm working on other urgent bugs.

	Makoto Kato [:m_kato]
	Comment 10 • 7 years ago

I can reproduce this on Firefox 52 and 53, but I cannot reproduce on the latest Nightly (55).  Is this fixed by other bugs?

	Makoto Kato [:m_kato]
	Comment 11 • 7 years ago

maybe bug 1175418?  I will check by mozregression.

	Makoto Kato [:m_kato]
	Comment 12 • 7 years ago

This is fixed by bug 1175418.

	Aryeh Gregor (:ayg) (no longer with Mozilla)
	Comment 13 • 7 years ago

For the record, if this is fixed by bug 1175418, that probably means the underlying code still doesn't handle adjacent text nodes correctly.  Bug 1175418 only removes one case where there will be adjacent text nodes, so this bug will still presumably occur in other cases where there are adjacent text nodes.  So I'm not sure this should be RESOLVED.  (But if no one is interested in finding a new test-case, I guess we may as well leave it.)