1159360 - Search engine bar does not appear above keyboard on GB

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

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

Apparently, before the final commit in bug 1137483 (adding a window background), the search engine bar moved above the keyboard in GB. Odd.

Comment 1

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

Apparently, this only happens sometimes. :| It appears the keyboard when the app is first started but I can't find the condition that makes this change.

Comment 2

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

Watching the:

 05-07 13:59:36.470 D/GeckoLayerClient( 3150): Window-size changed to (480,762)

logcat output, it seems when it is working correctly, the window size shrinks when the keyboard is shown and grows when the keyboard is hidden. When it is working incorrectly, when I click the EditText, the window shrinks but when I type, the window grows.

My best guess is that the touch events are going through the keyboard to the underlying Views (i.e. HomePager), which causes an inconsitent state where the keyboard is still up but the window is resized as if it dropped.

This is backed up by the fact that when I paste text into the EditText and click into the text, raising the keyboard, the search bar is above the keyboard. Typing into the field here keeps the search bar above the keyboard. Deleting all of the text (showing the HomePager) and typing again will put the search bar below the keyboard.

Comment 3

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

Downloaded a 39 build and it seems the window shrinks when the keyboard is shown but grows when it hides - this is the opposite of the desired former behavior so it seems this issue was pre-existing. Perhaps Android is using the "stateUnspecified" flag rather than "adjustResize"?

Comment 4

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

I backed out all the changesets from bug 1137483 and it seems the non-resize problem is still happening. Apparently something changed between trunk and 39 that causes this not to work. Time to do some Nightly regression hunting.

Comment 5

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

The issue does not appear on the build from 4/24 [1] but appears on the build from 4/25 [2]:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22a157f7feb7&tochange=f214df6ac75f

[1]: ftp://ftp.mozilla.org/pub/mobile/nightly/2015-04-24-03-02-04-mozilla-central-android-api-9/
[2]: ftp://ftp.mozilla.org/pub/mobile/nightly/2015-04-25-03-02-08-mozilla-central-android-api-9/

Comment 6

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

I backed out bug 1157534 [1] and it mostly works correctly (and may actually be the previous behavior): when you initially hit the EditText and type, the window expands. However, closing and reopening the keyboard will fix this behavior.

I have no idea why the patch in bug 1157534 would affect this code at all. o_o

[1]: https://hg.mozilla.org/mozilla-central/rev/549be4ee6dca

Comment 8

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

Tracking data from bug 1221082.

Comment 9

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

Attachment: Changes to BrowserSearch since I stopped trying to fix this

Comment 10

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

I'm trying to figure out what changed from 43 to 44 and how this could have gotten fixed.

Most of the changes from comment 9 are actually in 43 and there is nothing super obvious. I wonder if a change like bug 1206628 could have fixed it, where it can re-layout the search engine bar after the keyboard is shown.

Comment 11

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

Try pushes to follow because I need to rip up my mozconfigs to get beta to build so try is easier.

Comment 12

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=179fbb79d920

Comment 13

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

We'll track 43 for now, unless I decide it's not worth pursuing.

Comment 14

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

Rebasing bug 1206628 did not fix this.

Comment 15

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

The changes cascading from bug 1186683 were pretty drastic and landed in 44+ – perhaps it's related to one of them? There were also the search suggestion changes (local search history) but I doubt that's related.

Comment 16

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

After looking at the remaining changesets from comment 9, I think bug 1186683 and its follow-ups are to blame. Let's see if there's anything to take away from them.

Comment 17

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6f6f1f6c8069

Comment 18

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

Bug 1186683 doesn't seem to fix it and I already tested bug 1206628 (which depends on the former).

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking for 43 since this sounds like a recent regression.

Comment 20

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

The solution is non-obvious and it's fixed in the next version – I don't think this is worth the time to fix.

Comment 21

[Liz Henry (:lizzard) (relman/hg->git project)]

Makes sense. Thanks Michael. Marking wontfix.