1419803 - Typing into textarea or input element inside customElement duplicates characters on Android

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P2)

Description

[Adrian Aichner [:anaran]]

Just type a key into the textarea at
https://anaran.github.io/import/
and notice how characters get duplicated a funny way on Android.

123 -> 321
abc -> abcabcaba
123abc -> cba321
abc123 -> abc123abc12abc1abc1abcabcaba

Use linux to see a crash instead, as reported in Bug 1419799.

input elements inside custom elements show same problem on Android, but work fine on linux.

Pasting text into these elements works correctly in my testing.

Comment 1

[Adrian Aichner [:anaran]]

To review and reproduce testcase locally, use this:

git clone https://github.com/anaran/import.git
git checkout gh-pages
python -m SimpleHTTPServer

Visit http://localhost:8000/

Comment 2

[Adrian Aichner [:anaran]]

testcase is also available as tarball at https://bugzilla.mozilla.org/show_bug.cgi?id=1419799#c4

Comment 3

[Adrian Aichner [:anaran]]

Attachment: shadowy_testcase.js

New minimal testcase now available at
https://raw.githubusercontent.com/anaran/import/9bf3e184ad4bfffb4b5377f0e03ff64018cf6164/shadowy_testcase.js

Just run it in a Scratchpad on a newly opened tab (Ctrl+T) or just about:blank.

Use Scratchpad in WebIDE to remotely debug on Android device.

Comment 4

[Jessica Jong [:jessica] (inactive)]

Hi Adrian, can you still see this now that Bug 1419799 is fixed?

Comment 5

[Adrian Aichner [:anaran]]

(In reply to Jessica Jong [:jessica] from comment #4)
> Hi Adrian, can you still see this now that Bug 1419799 is fixed?

Hi Jessica, unfortunately this bug is still around in

navigator.buildID
20171220100049

navigator.userAgent
Mozilla/5.0 (Android 6.0.1; Mobile; rv:59.0) Gecko/59.0 Firefox/59.0

Comment 6

[Jessica Jong [:jessica] (inactive)]

Thanks, Adrian.
I set up my environment and was able to reproduce this too using the testcase in attachment 8934060 [details].

Typing "123" shows "321", and printing document.getElementsByTagName("div")[0].shadowRoot.firstChild.value gives "321" too.

Comment 7

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v1.

I saw a bunch of warnings:

I/Gecko   (13535): [13535, Main Thread] WARNING: 'startNode->GetUncomposedDoc() != mPresShell->GetDocument()', file /home/jessica/hg/fennec/dom/events/ContentEventHandler.cpp, line 312
I/Gecko   (13535): [13535, Main Thread] WARNING: 'NS_FAILED(rv)', file /home/jessica/hg/fennec/dom/events/ContentEventHandler.cpp, line 380

So I changed to use GetComposedDoc() instead, which makes sense I think.
The warnings are shown in Desktop too, but it looks like we ignore the warning/error result in Desktop?

There are still a lot of use `GetUncomposedDoc` that needs to be checked, we will track them in Bug 1413105.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 8940656 [details] [diff] [review]
patch, v1.

yeah, makes sense.

Comment 9

[Jessica Jong [:jessica] (inactive)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0f5b3153b3398da06031d5c5fd0b79f616587c33&duplicate_jobs=visible

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ba9bb352b5d
Use GetComposedDoc instead of GetUncomposedDoc in ContentEventHandler. r=smaug

Comment 11

[Bogdan Tara[:bogdan_tara | bogdant]]

https://hg.mozilla.org/mozilla-central/rev/2ba9bb352b5d