Closed
Bug 810171
Opened 12 years ago
Closed 11 years ago
Text input field at bottom of web page is hidden when VKB opens
Categories
(Firefox for Android Graveyard :: Keyboards and IME, defect)
Tracking
(firefox16 wontfix, firefox17 wontfix, firefox18 affected, firefox19 verified)
VERIFIED
FIXED
Firefox 19
People
(Reporter: cpeterson, Assigned: kats)
References
Details
Attachments
(1 file)
5.86 KB,
patch
|
cpeterson
:
review+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•12 years ago
|
||
WFM. What device?
Reporter | ||
Comment 2•12 years ago
|
||
Galaxy Nexus, Note, and S II.
Assignee | ||
Comment 3•12 years ago
|
||
Oh weird. I was testing on the GN as well - I see it now, some of the time. Looks like a race condition :(
Assignee | ||
Comment 4•12 years ago
|
||
I wrote a test for this. It fails.
Assignee | ||
Comment 5•12 years ago
|
||
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.
Assignee | ||
Comment 6•12 years ago
|
||
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
Assignee | ||
Updated•12 years ago
|
Attachment #680239 -
Flags: review?(cpeterson)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → bugmail.mozilla
Status: NEW → ASSIGNED
Reporter | ||
Comment 7•12 years ago
|
||
(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.
Reporter | ||
Comment 8•12 years ago
|
||
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+
Reporter | ||
Comment 9•12 years ago
|
||
Bug 810933 only affects Nightly 19, but this VKB bug affects 16, 17, and 18. Can that fix be uplifted?
Assignee | ||
Comment 10•12 years ago
|
||
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.
Assignee | ||
Comment 11•12 years ago
|
||
Landed test with nits addressed: https://hg.mozilla.org/integration/mozilla-inbound/rev/d78db2d4195f
Assignee | ||
Comment 12•12 years ago
|
||
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.
Comment 13•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d78db2d4195f
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 19
Updated•12 years ago
|
status-firefox19:
affected → ---
Comment 14•12 years ago
|
||
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
status-firefox19:
--- → verified
Comment 15•11 years ago
|
||
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 → ---
Assignee | ||
Comment 16•11 years ago
|
||
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: 12 years ago → 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 17•11 years ago
|
||
Filed bug 839199 for the regression.
Updated•3 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
•