Closed Bug 810171 Opened 9 years ago Closed 8 years ago

Text input field at bottom of web page is hidden when VKB opens

Categories

(Firefox for Android Graveyard :: Keyboards and IME, defect)

ARM
Android
defect
Not set
normal

Tracking

(firefox16 wontfix, firefox17 wontfix, firefox18 affected, firefox19 verified)

VERIFIED FIXED
Firefox 19
Tracking Status
firefox16 --- wontfix
firefox17 --- wontfix
firefox18 --- affected
firefox19 --- verified

People

(Reporter: cpeterson, Assigned: kats)

References

Details

Attachments

(1 file)

STR:
1. Load this Bugzilla page or Hacker News: https://news.ycombinator.com/
2. Scroll to the bottom of the page
3. Tap the input focus in the "Search" box

RESULT:
The VKB will open, but the text input field does not scroll into view. The VKB hides the text input field, even if you start typing.

This does not look like a regression. I can repro in Firefox 16, 17, 18, and 19.
WFM. What device?
Galaxy Nexus, Note, and S II.
Oh weird. I was testing on the GN as well - I see it now, some of the time. Looks like a race condition :(
Attached patch TestSplinter Review
I wrote a test for this. It fails.
Turns out the test passes with the patch from bug 810933. I also can't reproduce with the STR comment #0 on my local build with that patch applied. It could just be the race acting up again.
This seems to be working for me now. :cpeterson, can you try to reproduce with the patch from bug 810933 applied? (It just landed on central recently and has been on inbound since yesterday). I pushed my test to try [1] and ran it a few times, seems to pass every time so I'll probably land that shortly.

[1] https://tbpl.mozilla.org/?tree=Try&rev=af9ec5ac9fd9
Attachment #680239 - Flags: review?(cpeterson)
Assignee: nobody → bugmail.mozilla
Status: NEW → ASSIGNED
(In reply to Kartikaya Gupta (:kats) from comment #6)
> This seems to be working for me now. :cpeterson, can you try to reproduce
> with the patch from bug 810933 applied? (It just landed on central recently
> and has been on inbound since yesterday). I pushed my test to try [1] and
> ran it a few times, seems to pass every time so I'll probably land that
> shortly.
> 
> [1] https://tbpl.mozilla.org/?tree=Try&rev=af9ec5ac9fd9

Your try build works for me.
Comment on attachment 680239 [details] [diff] [review]
Test

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

LGTM with nits

::: mobile/android/base/tests/testVkbOverlap.java.in
@@ +42,5 @@
> +
> +        paintExpecter = mActions.expectPaint();
> +        // the input field should be in the bottom-left corner, so tap thereabouts
> +        meh.tap(5, mDriver.getGeckoHeight() - 5);
> +        paintExpecter.blockUntilClear(LESS_THAN_CURSOR_BLINK_PERIOD);

Please add a comment explaining the relevance of waiting for LESS_THAN_CURSOR_BLINK_PERIOD.

@@ +46,5 @@
> +        paintExpecter.blockUntilClear(LESS_THAN_CURSOR_BLINK_PERIOD);
> +        painted = mDriver.getPaintedSurface();
> +        try {
> +            int newCount = countGreenPixels(painted);
> +            mAsserter.ok(newCount >= (greenPixelCount * 0.9), "testVkbOverlap", "Found " + newCount + " green pixels after tapping; expected " + greenPixelCount);

Please add a comment detailing that the green pixels are the text field, so the screen's green pixel count should be (approximately) the same after the page scrolls up to accommodate the open VKB.
Attachment #680239 - Flags: review?(cpeterson) → review+
Bug 810933 only affects Nightly 19, but this VKB bug affects 16, 17, and 18. Can that fix be uplifted?
bug 810933 is a regression in 19 only and shouldn't be uplifted. I can repro on 16 and 17 as well but I think those are caused by a different problem. I'm not seeing it on 18.
So 17 is on final beta and will be out the door in a week so it seems unlikely that we'll get a patch for that accepted for that. I can try to repro it harder on 18 and fix it there but so far I haven't had any luck. I'm running into plenty of other issues though.
https://hg.mozilla.org/mozilla-central/rev/d78db2d4195f
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
I cannot reproduce this issue anymore on the latest Nightly. The page scrolls up so the input fields from the bottom of the page will always remain into view. Closing bug as verified fixed on:

Firefox 19.0a1 (2012-11-16)
Device: Galaxy S2
OS: Android 4.0.3
Status: RESOLVED → VERIFIED
This is not working in the current nightly, at least in some cases.

Case 1: On the Galaxy Nexus in portrait orientation
Load news.ycombinator.com
Tap on Search field at bottom of page
a) -> sometimes VKB comes up, page is zoomed and repositioned, but Search box is not visible (it is off to the right)
b) -> sometimes VKB comes up, page is repositioned but not zoomed, Search box is obscured by VKB

Case 2: Galaxy Nexus in portrait orientation
Load robocop_input.html (from testVkbOverlap)
Scroll down and tap input field
a) -> usually VKB comes up, page is repositioned and zoomed, input field is visible (works correctly)
b) -> sometimes VKB comes up, page is repositioned (and zoomed?), but input field is partially obscured by VKB

Case 3: Galaxy Nexus in landscape orientation
Load robocop_input.html (from testVkbOverlap)
Scroll down and tap input field
a) -> VKB comes up and obscures input field (consistently)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I'll open a new bug. Re-opening a bug that was fixed ages ago (and particularly with specific target milestone/status flags) gets painful.
Status: REOPENED → RESOLVED
Closed: 9 years ago8 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Filed bug 839199 for the regression.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.