Android Question Bug in webview with contenteditable element

bernardR

Member
Licensed User
Hello,
I am stuck in the use of a contenteditable element of an html page by a bug that I can't get around.
I isolated it in the very small program attached.

Start the program
1. Place the cursor in the word A1B2CD3E4F5G6HIJKLM before G (a letter, not a number)
2. Type the sequence of the 3 keys: Enter + Backspace + Enter
Result: A1B2CD3E4F5; the end of the line disappears ...

Is this bug workaround, for example by intercepting the keypress event ?
Thanks for your help
 

Attachments

  • bugWVedit.zip
    8.6 KB · Views: 200

drgottjr

Expert
Licensed User
Longtime User
you may need to try with keydown for the backspace key. keypress != keydown. and not all browsers handle it the same way. plus webview isn't an actual browser. i'm going to try it myself, but it's late here. maybe you're just getting up after a socially distant night's sleep...
 
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
it's very interesting what happens when you trap for keydown and backspace. also, don't forget "backspace" is a funny beast because of the implied delete that goes with it. plus we are dealing with android's keyboard. not everything is trappable.

this seems to be a well-known issue
 
Last edited:
Upvote 0

bernardR

Member
Licensed User
There is in the 'zip' the file testeditable.html.
If used directly in Chrome (Windows or Android), the bug does not occur.
It only occurs if the file is loaded in an android webview.
 
Last edited:
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
on my windows chrome (Version 80.0.3987.149), the "bug" is clearly there. see attached. that you don't see the problem looking at the html doesn't mean it isn't there.
the return/enter key generates a new node. when you hit the backspace key, the new node is not un-noded back to original version. bug, feature, or failure in re-inventing the wheel - it is what it is. (which, by the way, is not a bug attributable to webview)
 

Attachments

  • chrome.png
    chrome.png
    7.4 KB · Views: 183
Upvote 0

bernardR

Member
Licensed User
Thank you so much. That's right.
A node is created, but no fault in the display.
On the other hand, in the webview, part of the text disappears. Why ?
And why is it not the same thing if you place the cursor just before a number before doing Enter, Backspace, Enter?
 
Upvote 0

drgottjr

Expert
Licensed User
Longtime User
there is a lack of consistency in the way the so called contenteditable (maybe contentedible would be easier to say) element is implemented. this sort of thing has been a problem since the earliest days of people racing to add functionality to html. we've had a contenteditable feature since the beginning: "<textarea>". the very page we post our posts to is using it. seems to work just fine.
as for the webview part disappearing, it doesn't disappear on my device. when you hit backspace, the text appears to re-attach itself, just like it does on the full-blown chrome browser.
i'm pretty sure i put the cursor at different spots and got the same result, but having everything behave differently if you put the cursor before a number would, in fact, be a bug. but what's the point? you can't very well tell users to make sure they don't put the cursor before a number...
long live textarea!
 
Upvote 0
Top