Open Bug 1327102 Opened 8 years ago Updated 4 years ago

Browser puts caret in different places of contenteditable elemen (depending on styling) when it's focused programmatically or via Tab key

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox50 --- affected
firefox51 --- affected
firefox52 --- affected
firefox53 --- affected

People

(Reporter: arni2033, Unassigned)

References

(
URL
)

Details

>>>   My Info:   Win7_64, Nightly 49, 32bit, ID 20160526082509
STR_1:
1. Open url [1]
2. In less than 3 seconds click outside of contenteditable field
3. Wait 3 seconds

STR_2:
1. Open url [2]
2. In less than 3 seconds click outside of contenteditable field
3. Wait 3 seconds

STR_3:
1. Open url [3]
2. In less than 3 seconds click outside of contenteditable field
3. Wait 3 seconds


> [1] data:text/html,<!DOCTYPE html><html><head></head><body onload="D=document.querySelector(`.d`);D.focus();setTimeout(`D.focus()`,3000);"><div contenteditable class="d">zxcv</div></body></html>
> [2] data:text/html,<!DOCTYPE html><html><head></head><body onload="D=document.querySelector(`.d`);D.focus();setTimeout(`D.focus()`,3000);"><div contenteditable class="d">zxcv</div><div></div></body></html>
> [3] data:text/html,<!DOCTYPE html><html><head></head><body onload="D=document.querySelector(`.d`);D.focus();setTimeout(`D.focus()`,3000);"><div contenteditable class="d">zxcv</div><table><tbody><tr><td></td></tr></tbody></table></body></html>


AR:
 Results of each scenario is written as a pair of words (start/end). 1st word represents caret
 position in contenteditable field after Step 1, the 2nd word represents caret position after Step 3
 STR_1 - END END
 STR_2 - START END
 STR_3 - START START

ER:
 When contenteditable field is focused programmatically or via Tab key, caret should always be moved
 to the same place (either start or end). I.e. either "END" in all 6 cases, or "START" in all 6 cases.


Notes:
1) URL in the form above has all 3 links [1]-[3] on one page to simplify the testing
2) It seems that behavior described in AR depends only on "display" property, e.g. "block" or "table".
3) Actually, when <textarea> is focused programmatically or via Tab key, it always preserves caret
   position, and it would be nice to have the same feature for [contenteditable] elements,
   but this is not what reported in this bug. In fact I never reported that
Product: Firefox → Core
No longer blocks: 1277113
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID 	20170119030211

The issue is reproducible on the latest Firefox release (50.1.0) and on the latest Nightly (53.0a1).
status-firefox50: --- → affected
status-firefox51: --- → affected
status-firefox52: --- → affected
status-firefox53: --- → affected
Component: Untriaged → Editor
Priority: -- → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.