Open Bug 1364426 Opened 7 years ago Updated 2 years ago

WebDriver:ElementSendKeys has to set caret for content-editable elements after any child content

Categories

(Remote Protocol :: Marionette, defect, P3)

Product:
Remote Protocol
Component:
Marionette
Version:
Version 3
Type:
defect

Tracking

(Not tracked)

People

(Reporter: whimboo, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [webdriver:backlog])

Instead of adding the text which gets send via ´sendKeys´ to an content editable element at the end, the text appears at the beginning: def inline(doc): return "data:text/html;charset=utf-8,{}".format(urllib.quote(doc)) def test_testcase(self): self.marionette.navigate(self.marionette.absolute_url("test_clearing.html")) #self.marionette.navigate(inline("<div id='content-editable' contentEditable='true'>This is a contentEditable area</div>")) elem = self.marionette.find_element(By.ID, "content-editable") elem.send_keys(" with text") self.assertEqual(elem.text, "This is a contentEditable area with text") The result is: AssertionError: u' with textThis is a contentEditable area' != 'This is a contentEditable area with text' This only happens when I use the loaded HTML page but works fine when I use the inline HTML code. Not sure what the difference is here.
Priority: -- → P3
Blocks: 1417925
No longer blocks: webdriver
Summary: sendKeys doesn't append text to content-editable area but put it at the front → sendKeys doesn't append text but puts it at the front
Summary: sendKeys doesn't append text but puts it at the front → sendKeys doesn't append text to content-editable area but put it at the front
Blocks: webdriver
Priority: P3 → P2
Summary: sendKeys doesn't append text to content-editable area but put it at the front → WebDriver:ElementSendKeys doesn't append text to content-editable area but put it at the front
The problem here actually only occurs when there is a new line character after the div element like: > self.marionette.navigate(inline("<div id='content-editable' contentEditable='true'>This is a contentEditable area</div>\n")) In such a case focusing the content editable element sets the caret to the beginning of the test, while when the new line is missing it is as the end. Further in `moveCaretToEnd()` we do not handle content editable elements yet.
This is actually a good example to prove the to be added features of the WebDriver spec: > element is content editable > Set the text insertion caret after any child content.
Summary: WebDriver:ElementSendKeys doesn't append text to content-editable area but put it at the front → WebDriver:ElementSendKeys has to set caret for content-editable elements after any child content

Note that we should be careful to only update the caret position if the element does not have focus yet (see current issue for regular inputs at https://github.com/mozilla/geckodriver/issues/2015)

We had a similar fix for normal input fields and this got fixed in bug 1203074. Looks like we missed to also apply it to content editable fields at this time.

Lets discuss if we want / can get this fixed in a timely manner given that this is still marked as a P2 but was missed for too long.

See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1203074
Whiteboard: [webdriver:triage]

Note that contenteditable can end with:

  • <br> element which is invisible if the editing host is a block
  • white space only invisible text node if the exiting host is a block
  • preformatted \n which is invisible if the editing host is a block and white-space: pre or similer style
  • empty inline elements such as <b><i></i></b> which are mainly created by editor's bug
  • non-editaable element such as <span contenteditable="false">
  • atomic and/or replaced elements such as <img>, <hr>, <input> and <textarea>

We should have a look if this has been fixed. I'll have a look.

Flags: needinfo?(hskupin)

Masayuki: I think bug 1791736 should have fixed this. Do you agreee that the patch there will handle the edge cases you identified above? Maybe there's something different we should be doing here?

Flags: needinfo?(masayuki)
Severity: normal → S3

According to the change here, it depends on how HTMLEditor handles with collapsed Selection at end of an editing host which have non-text node as its last leaf node, i.e., the behavior is not stable. And the patch does not contain enough test for the cases. Therefore, at least we should add edge case tests.

Flags: needinfo?(masayuki)
Flags: needinfo?(hskupin)
Flags: needinfo?(jdescottes)
Priority: P2 → P3
Whiteboard: [webdriver:triage] → [webdriver:backlog]
Product: Testing → Remote Protocol
You need to log in before you can comment on or make changes to this bug.