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

Status: NEW

(Remote Protocol :: Marionette, defect, P3)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 4

[Julian Descottes [:jdescottes]]

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)

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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>

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

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

Comment 9

[James Graham [:jgraham]]

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?

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

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.

Comment 11

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Hi Julian, have you had the time to check for the needinfo request that you set for yourself?