Keyboard Apps (Hacker's Keyboard, Swype) don't update screen correctly

RESOLVED WORKSFORME

Status

()

Firefox for Android
Toolbar
RESOLVED WORKSFORME
4 years ago
2 years ago

People

(Reporter: Dan Weiss, Unassigned)

Tracking

34 Branch
ARM
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
Build ID: 20140923194127

Steps to reproduce:

This problem affects text fields on web pages, but not in the URL bar.  It seems to vary from page to page, some pages are more affected than others.  Example website where things aren't working: http://www.dwedit.org/passhash/

Whenever I type into a text field using either Hacker's Keyboard or Swype, the text field does not respond properly.  Sometimes it will advance the cursor without drawing a character, and other times it will not even move the cursor or draw the character.  Likewise, when I erase characters with the backspace key, the text does not update.  Either the text cursor position will update with each keystroke, or sometimes it won't.

When I click elsewhere to dismiss the keyboard, all the actions suddenly take effect, and the text in the textbox becomes correct.

If I use the default system keyboard (Samsung Keyboard), everything works perfectly, there are no issues with the screen refreshing.
Which version of Firefox are you using, which device? Do you see the same behaviour using Nightly (http://nightly.mozilla.org)?
Flags: needinfo?(danweiss)
OS: Windows XP → Android
Hardware: x86 → ARM
(Reporter)

Comment 2

4 years ago
Platform: Samsung Galaxy S4 (Verizon), Model number: SCH-I545, Android 4.42 (Kitkat).
I've also tested it on Nightly and also saw the same problem.
Sequence of steps that I got to trigger the problem:  (On Nightly)
Select Hacker's Keyboard as the default IME
Go to http://www.dwedit.org/passhash/
Type something into the password field, such as 'aaaaaaaa', hit enter  (no problems yet)
click the MD5 button
Selected text shows up in the Hash textbox, looking blurry and slightly glitchy.
Hold down finger over Hash text box to make toolbar appear, select cut.
Return to password field, delete the characters (there is no visible effect when deleting characters)

I also tried Swype, and it didn't even display any input when typing into the password field.  (until clicking off then clicking elsewhere, then all characters appeared in the password field as bullets)
I wonder if this has to do with how the page is scaled.
Flags: needinfo?(danweiss)
Mark, any thoughts?
Flags: needinfo?(markcapella)
mmm ... perhaps Keyboards and IME ... 

Quick testing I see that if I tap into the password field and tap again to trigger the visual SelectionHandler Caret display, subsequent keyboard taps advance the caret forward/backward as if we're properly tracking the underlying data changes.

More interestingly, the main / blinking / vertical line / selection indicator is visible, but not blinking nor movable, basically uncoupled from the Java UI indicator.

https://www.dropbox.com/s/jhnmux8ynbefj1t/bug1077716.png?dl=0

Something "special" about this site? What other pages can you see it on? This seems edge-case, as I can observe it on release v33 and you'd think someone would've noticed.
Flags: needinfo?(markcapella) → needinfo?(danweiss)
Seems related to the viewport size setting. The page stops updating with this meta tag,

> <meta name="viewport" content="width=300, user-scalable=no">

But the page *does* update with this meta tag,

> <meta name="viewport" content="width=device-width, user-scalable=no">

And this line shows up in the logs,

> D/GeckoLayerClient: Aborting update due to viewport not in display-port
Component: Keyboards and IME → Graphics, Panning and Zooming
Created attachment 8518353 [details] [diff] [review]
Abort update only if viewport is outside of display-port (v1)

Are we checking for aborts here correctly? AFAICT, it currently checks that the display-port must contain all of the viewport. That means we abort the update even if a small part of the viewport is outside of the display-port. Is that intended?
Attachment #8518353 - Flags: review?(snorp)
Comment on attachment 8518353 [details] [diff] [review]
Abort update only if viewport is outside of display-port (v1)

Review of attachment 8518353 [details] [diff] [review]:
-----------------------------------------------------------------

Not touching this review with a 10ft pole
Attachment #8518353 - Flags: review?(snorp) → review?(bugmail.mozilla)
Comment on attachment 8518353 [details] [diff] [review]
Abort update only if viewport is outside of display-port (v1)

Review of attachment 8518353 [details] [diff] [review]:
-----------------------------------------------------------------

The behavior is intentional, yes. Can you provide the actual values you're seeing in viewportMetrics and the displayport passed in (x, y, width, height)? I've run into rounding issues with the C++ version of this code and there might be a similar problem here.
Attachment #8518353 - Flags: review?(bugmail.mozilla) → review-
On a Nexus 4 (device width 384px),

When meta viewport width < device-width, there are two updates at a time, e.g.

Display rect: x=0.0 y=0.0 w=769.871 h=512.0192
viewportRect: x=0.0 y=0.0 w=768.0   h=660.0
pageRect:     x=0.0 y=0.0 w=769.871 h=565.3766
Update aborts due to viewport not in display-port

Display rect: x=0.0 y=0.0 w=769.871 h=565.37665
viewportRect: x=0.0 y=0.0 w=768.0   h=660.0
pageRect:     x=0.0 y=0.0 w=769.871 h=565.3766
Update aborts due to stale low-precision

When meta viewport width is device-width, there is one update at a time, e.g.
Display rect: x=0.0 y=0.0 w=768.0 h=564.0
viewportRect: x=0.0 y=0.0 w=768.0 h=660.0
pageRect:     x=0.0 y=0.0 w=768.0 h=564.0
Update completes

When meta viewport width > device-width, there is one update at a time, e.g.
Display rect: x=0.0 y=0.0 w=800.0 h=587.5
viewportRect: x=0.0 y=0.0 w=768.0 h=660.0
pageRect:     x=0.0 y=0.0 w=800.0 h=587.5
Update completes
Flags: needinfo?(danweiss) → needinfo?(bugmail.mozilla)
(In reply to Jim Chen [:jchen] from comment #9)
> On a Nexus 4 (device width 384px),
> 
> When meta viewport width < device-width, there are two updates at a time,
> e.g.
> 
> Display rect: x=0.0 y=0.0 w=769.871 h=512.0192
> viewportRect: x=0.0 y=0.0 w=768.0   h=660.0
> pageRect:     x=0.0 y=0.0 w=769.871 h=565.3766
> Update aborts due to viewport not in display-port
> 
> Display rect: x=0.0 y=0.0 w=769.871 h=565.37665
> viewportRect: x=0.0 y=0.0 w=768.0   h=660.0
> pageRect:     x=0.0 y=0.0 w=769.871 h=565.3766
> Update aborts due to stale low-precision

So it seems like the height of the displayport rect is wrong the first time through; presumably that's the high-precision draw attempt. On the second one it's correct but that is a low-precision draw attempt and there's a new paint pending so it gets skipped. Do these two things just cycle over and over? If so then it looks like the critical displayport (which is what gets passed in as the displayport on the first attempt) is not computed correctly.
Flags: needinfo?(bugmail.mozilla)
I'm seeing these when a textbox cursor is blinking, for example. Every time the cursor is supposed to appear or disappear, these two attempts happen; then nothing happens until the next cursor draw/erase, and the same two attempts happen again.
Are the STR in comment 2 accurate? I installed Hacker's Keyboard on my Nexus 4 and loaded the passhash page in nightly. However when I type in the password or hash fields nothing is blurry. Also long-pressing on the hash doesn't make the action bar appear so I couldn't follow the STR as-is.
Apparently it's fixed already as I can't reproduce it anymore. I bisected it to the 2014-11-07 nightly but I'm not sure which bug fixed it.

My steps are,
* Go to http://people.mozilla.org/~nchen/tests/test-password.html
* Tap on password field
* Bug exists when the cursor is not blinking
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.