1230617 - Editing text in an input field causes the actionbar to appear and disappear on each keystroke

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Text Selection, defect)

Description

[Kartikaya Gupta (email:[e-mail])]

In today's nightly I'm finding that often while editing text in a text field the action bar keeps going in and out and it's very distracting. I'm assuming this is a regression from the native handles but it might be something else. I'm testing on a Nexus 4. I can repro using the text field on the page at http://people.mozilla.org/~kgupta/bug/1180295-2.html, for example.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Capella, have you seen this?

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

I can't repro on 6p

Comment 3

[Kartikaya Gupta (email:[e-mail])]

Video of what it looks like: http://people.mozilla.org/~kgupta/bug/1230617.3gp

Comment 4

[Mark Capella [:capella]]

Weird, I can't repro on my GS3 nor my N7 using either the default Google IME demonstrated in the video, nor my preferred SwiftKey   :-/

Comment 5

[Teodora Vermesan (:TeoVermesan)]

I could reproduce the issue on 04-12 mc build, but could not reproduce the issue on 03-12 mc build.
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=85cf2e720a8405c43eabc9b34cce381b66d25ef9&tochange=e02b17a2b5b8df7bb84f325fc08eedd2f3cab755

For fx-team builds:
1449163461: not affected 		
1449167604: affected

pushlog: http://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=4c9ca7614d701d28549ef734d41dcce5ac37cba2&tochange=65b8c89ff1b737c5e58523b6faf89299ca674e4e

Bug 1215959?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

I made a local build with logging at the start of BrowserApp.startActionModeCompat and BrowserApp.endActionModeCompat, but they didn't get hit. Is there any other way that the action bar could be getting made visible?

Comment 7

[Mark Capella [:capella]]

Ah nice :) I'm hoping to catch you in mozlando re: this and look myself if possible ...

The Carets (and by extension the ActionBar) visibility state update (Show/Hide) decision is [0]
I usually hook into PresShell to watch the events fly by, but the more targeted point for Caret handling is [1]

[0] http://mxr.mozilla.org/mozilla-central/source/layout/base/AccessibleCaretManager.cpp?rev=716f4df6fad5#183
[1] http://mxr.mozilla.org/mozilla-central/source/layout/base/AccessibleCaretEventHub.cpp?rev=934c1ef52c88#454

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Logging patch

We should definitely try to meet up sometime this week if you're here. But in the meantime, here's the logging patch I applied based on your comment and here's the output from two keypresses, both of which caused the action bar to flash.

12-08 22:13:03.817 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 7
12-08 22:13:03.817 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 7
12-08 22:13:03.817 I/Gecko   ( 7792): kats: UpdateCarets(0) called, mLastUpdateCaretMode is 1
12-08 22:13:03.817 I/Gecko   ( 7792): kats: UpdateCarets(1) called, mLastUpdateCaretMode is 1
12-08 22:13:03.837 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.837 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.837 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.837 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.908 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.908 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:03.908 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:03.908 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:03.908 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:03.918 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:05.890 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 7
12-08 22:13:05.890 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 7
12-08 22:13:05.890 I/Gecko   ( 7792): kats: UpdateCarets(0) called, mLastUpdateCaretMode is 1
12-08 22:13:05.890 I/Gecko   ( 7792): kats: UpdateCarets(1) called, mLastUpdateCaretMode is 1
12-08 22:13:05.900 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.900 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.910 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.910 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 4
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6
12-08 22:13:05.920 I/Gecko   ( 7792): kats: ACEH::HandleEvent got event type 6

Comment 9

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

AccessibleCaretEventHub has some log built-in. You could "export NSPR_LOG_MODULES=AccessibleCaret:5" to use that.

I would happy to help if we could meet sometime in orlando.

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: Action bar NSPR log

Here's a log of a couple of keypresses with the NSPR_LOG_MODULES thing set like you suggested

Comment 11

[Kartikaya Gupta (email:[e-mail])]

For the record capella and I compared our keyboard settings and this bug seems to be reproducible specifically on the stock android keyboard with auto-correction disabled (so typing words doesn't enter the composition state).

Comment 12

[Mark Capella [:capella]]

Attachment: bug1230617.diff

Aha! It looks like I forgot to pull some provisional code :-)

kats, can you check this? It fixes the issue for me locally, and I don't see further regressions (as expected originally).

Comment 13

[Kartikaya Gupta (email:[e-mail])]

Comment on attachment 8697370 [details] [diff] [review]
bug1230617.diff

Yup, this fixes it for me. Thanks!

Comment 14

[Mark Capella [:capella]]

Awesome, thanks !

I'm going to sit on the fix for a day or two, then over to snorp for review. Let me know if anything else leaks out before then   :-)

Comment 15

[Mark Capella [:capella]]

Comment on attachment 8697370 [details] [diff] [review]
bug1230617.diff

No reason to sit on this :-)

Comment 16

[Mark Capella [:capella]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5eea6d468d91

Comment 17

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/28e50891e0b3

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/28e50891e0b3

Comment 19

[Teodora Vermesan (:TeoVermesan)]

Tested using:
Device: Nexus 6 (Android 6.0)
Build: Firefox for Android 46.0a1 (2015-12-22)

Typing in a text box, does not make the action bar to appear and disappear anymore on each keystroke.
But:

- on latest Aurora:
-If I go to facebook.com
-Tap the username field and type w
-Type once again the text field, so that the action bar appears
 => the action bar remains displayed

-on latest Nightly:
-If I go to facebook.com
-Tap the username field and type w
-Type once again the text field, so that the action bar appears
=> the action bar disappears after a few seconds

Is this expected?

Comment 20

[Mark Capella [:capella]]

Yes, this is expected. The basic design delivered by the new layout/AccessibleCaret dissapears after a short timeout by default.

You can change the timeout duration via about:config using |layout.accessiblecaret.timeout_ms|.

Setting it to 0, disables the auto-timeout.

Comment 21

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

FYI, the auto timeout of carets had been disabled by default in bug 1268410.