Closed
Bug 1230617
Opened 9 years ago
Closed 9 years ago
Editing text in an input field causes the actionbar to appear and disappear on each keystroke
Categories
(Firefox for Android Graveyard :: Text Selection, defect)
Firefox for Android Graveyard
Text Selection
Tracking
(firefox46 fixed, fennec46+)
RESOLVED
FIXED
Firefox 46
People
(Reporter: kats, Assigned: capella)
References
()
Details
Attachments
(3 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
snorp
:
review+
kats
:
feedback+
|
Details | Diff | Splinter Review |
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•9 years ago
|
||
Capella, have you seen this?
tracking-fennec: --- → ?
Flags: needinfo?(markcapella)
I can't repro on 6p
Reporter | ||
Comment 3•9 years ago
|
||
Video of what it looks like: http://people.mozilla.org/~kgupta/bug/1230617.3gp
Assignee | ||
Comment 4•9 years ago
|
||
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 :-/
Flags: needinfo?(markcapella)
Comment 5•9 years ago
|
||
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?
Reporter | ||
Comment 6•9 years ago
|
||
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?
Flags: needinfo?(markcapella)
Assignee | ||
Comment 7•9 years ago
|
||
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
Flags: needinfo?(markcapella)
Reporter | ||
Comment 8•9 years ago
|
||
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•9 years ago
|
||
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.
Reporter | ||
Comment 10•9 years ago
|
||
Here's a log of a couple of keypresses with the NSPR_LOG_MODULES thing set like you suggested
Reporter | ||
Comment 11•9 years ago
|
||
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).
Assignee | ||
Comment 12•9 years ago
|
||
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).
Attachment #8697370 -
Flags: feedback?(bugmail.mozilla)
Reporter | ||
Comment 13•9 years ago
|
||
Comment on attachment 8697370 [details] [diff] [review]
bug1230617.diff
Yup, this fixes it for me. Thanks!
Attachment #8697370 -
Flags: feedback?(bugmail.mozilla) → feedback+
Assignee | ||
Comment 14•9 years ago
|
||
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 :-)
Assignee | ||
Comment 15•9 years ago
|
||
Comment on attachment 8697370 [details] [diff] [review]
bug1230617.diff
No reason to sit on this :-)
Attachment #8697370 -
Flags: review?(snorp)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → markcapella
Status: NEW → ASSIGNED
Attachment #8697370 -
Flags: review?(snorp) → review+
Assignee | ||
Comment 16•9 years ago
|
||
Comment 18•9 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox46:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 46
Updated•9 years ago
|
tracking-fennec: ? → 46+
Comment 19•9 years ago
|
||
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?
Flags: needinfo?(markcapella)
Assignee | ||
Comment 20•9 years ago
|
||
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.
Flags: needinfo?(markcapella)
Comment 21•9 years ago
|
||
FYI, the auto timeout of carets had been disabled by default in bug 1268410.
Reporter | ||
Updated•8 years ago
|
Reporter | ||
Updated•8 years ago
|
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•