845360 - screen area blanks when keyboard pops up

Status: RESOLVED DUPLICATE of bug 819183

(Firefox for Android Graveyard :: Toolbar, defect)

Description

[Tony Green]

Attachment: Screen before and after tapping in text box

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0
Build ID: 20130220104816

Steps to reproduce:

Tapped in the search box on the Firefox addons page.

Hardware: Huawei Ascend G300
OS: Android Gingerbread 2.3.6


Actual results:

Keyboard popped up, top half of screen went white making it impossible to see what I'm typing.

I'm guessing the same will happen if I try to use a text box on any other website, but due to bug 845356 I can't prove or disprove this, as the browser has also decided that it prefers offline mode.


Expected results:

Keyboard should pop up and the input box should remain visible.

Comment 1

[Aaron Train [:aaronmt]]

Scrikk

Comment 2

[Aaron Train [:aaronmt]]

Whoops; ignore above ^

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

I'm not able to reproduce this on a G300 running ICS.

Comment 4

[Tony Green]

A couple more notes from reporter.

I did see this behaviour when I installed the release version of Firefox a couple of months ago (sorry, can't remember the version as I removed it because I didn't like the automatic addition of bookmarks to the front page it used at the time).

I have an Android development environment installed, so I'm in a position to test any candidates for fixes.

I've run this with my device attached and taken a verbose log through Eclipse in case that gives any clues as to what's going on. The log runs from when I refreshed a Google search page, through clicking on the text box until it stopped logging.

Comment 5

[Tony Green]

Attachment: Eclipse log with device attached and displaying a page showing the problem

Comment 6

[(inactive) Jim Chen [:jchen] [:darchons]]

Looks like Bug 758190 fixed this bug in the latest Nightly

Comment 7

[Tony Green]

If someone can point me at where I can grab an APK with the new nightly, I can install it and see if it's fixed on my device.

Comment 8

[Kevin Brosnan [Ex-Mozilla]]

https://nightly.mozilla.org

Comment 9

[Kartikaya Gupta (email:[e-mail])]

I'm not entirely convinced this is a dupe of bug 758190. In that bug, the STR show a blank screen area after entering a URL in the awesomescreen, whereas in this one you're bringing up the keyboard while still on the content page. In the former scenario we do a pause/resume on the compositor because the LayerView is hidden whereas in the latter we do not. So this bug may be different - but if it's fixed, so much the better!

Comment 10

[Tony Green]

Sorry, doesn't fix the problem for me. So it looks like Kartikaya Gupta is probably right about it not actually being a duplicate of the other bug.

Comment 11

[Tony Green]

Just to clarify, this was fennec-22.0a1.multi.android-arm.apk

Comment 12

[Kartikaya Gupta (email:[e-mail])]

(In reply to Tony Green from comment #11)
> Just to clarify, this was fennec-22.0a1.multi.android-arm.apk

Yup.

(In reply to Tony Green from comment #10)
> Sorry, doesn't fix the problem for me. So it looks like Kartikaya Gupta is
> probably right about it not actually being a duplicate of the other bug.

That's unfortunate. Looking at the screenshots you posted I can't think of anything off the top of my head that would cause this behaviour. Does the visible area fix itself once you dismiss the keyboard? What about if you rotate the device? If you pan the page while it's in this bad state, does the blank area remain blank? Or does the page move up into the blank area and fix itself?

Comment 13

[Tony Green]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #12)

> That's unfortunate. Looking at the screenshots you posted I can't think of
> anything off the top of my head that would cause this behaviour. Does the
> visible area fix itself once you dismiss the keyboard? What about if you
> rotate the device? If you pan the page while it's in this bad state, does
> the blank area remain blank? Or does the page move up into the blank area
> and fix itself?

Apologies for the delayed reply; I've been a bit tied up.

The blanked out area DOES reappear if I dismiss the keyboard.
If I scroll the page up, whatever content was visible below the blank area appears to scroll behind it. EXCEPT that the cursor pointer (sorry, not sure of the correct term) scrolls up IN FRONT OF the blank area (picture to follow). So it appears that the blank area is being added with a z-index between that of the content and the pointer.

Just to make things even more complicated, I just closed the browser and reopened it, tapped on the input field and the content remained in place. BUT... when I dismissed the keyboard, I was left with a black area where it had been (picture to follow).

rotating the device shows a large input area (pic to follow). This may be a feature of the OS, as I see the same behaviour in some apps (though oddly, the default browser DOESN'T do this). Rather worryingly, when not focussed in an input field, the entire page is messed up in landscape mode (I'll raise a separate bug for this, as it's probably not relevant here.

Comment 14

[Tony Green]

Attachment: Picture showing effect of scrolling upwards with focus in input field

Comment 15

[Tony Green]

Attachment: Picture showing device in landscape mode. Note large input field at top. (lines in it are an artefact)

Comment 16

[Tony Green]

Attachment: Picture of strange effect after dismissing keyboard

Comment 17

[Kartikaya Gupta (email:[e-mail])]

(In reply to Tony Green from comment #13)
> The blanked out area DOES reappear if I dismiss the keyboard.
> If I scroll the page up, whatever content was visible below the blank area
> appears to scroll behind it. EXCEPT that the cursor pointer (sorry, not sure
> of the correct term) scrolls up IN FRONT OF the blank area (picture to
> follow). So it appears that the blank area is being added with a z-index
> between that of the content and the pointer.
> 
> Just to make things even more complicated, I just closed the browser and
> reopened it, tapped on the input field and the content remained in place.
> BUT... when I dismissed the keyboard, I was left with a black area where it
> had been (picture to follow).

Thanks for the info. The behaviour with the input field pointer is particularly interesting as it restricts the set of things that could be the problem. Just to make sure, are you using the stock android keyboard? Or are you using some custom 3rd party keyboard?

> rotating the device shows a large input area (pic to follow). This may be a
> feature of the OS, as I see the same behaviour in some apps (though oddly,
> the default browser DOESN'T do this).

This behaviour is expected. We switch to a full-screen input field when we detect that the height of the visible area of the screen is too small to reasonably show the input field in-place. We have some custom logic for this so it may not match what the default browser does.

Comment 18

[Tony Green]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #17)

> Thanks for the info. The behaviour with the input field pointer is
> particularly interesting as it restricts the set of things that could be the
> problem. Just to make sure, are you using the stock android keyboard? Or are
> you using some custom 3rd party keyboard?

Yes, it is the stock keyboard.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

Sorry for the delay. I was trying to put together a build with additional logging that might shed some light on the problem but honestly I don't even know where to put the additional logging because based on the screenshots I can't think of why this would happen. CC'ing Chris, BenWa, and snorp for any thoughts they might have.

The first screenshot seems to indicate that the GL surface is not positioned where it should be; instead of being anchored to the top of the window it is anchored to the bottom and ends up behind the keyboard. The blank space at the top seems to be the same size as the keyboard, so it looks like the GL surface is resized correctly but positioned incorrectly. But then the screenshot from comment 14 provides some additional information - the text cursor shown there is a Java layer positioned by the Java LayerRenderer, and it's in the "blank" area, so the GL surface must actually still include that area. So then it looks like the GL surface is in the right spot and the native compositor clip or something is wrong. I don't know where that would be though. Any suggestions?

Comment 20

[Chris Lord [:cwiiis]]

Does the patch on bug 819183 fix it?

Comment 21

[Benoit Girard (:BenWa)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #19)

The problem is when the surface size changes the compositor needs to paint the right frame with the right size and from my experience this tend to depend between preICS/ICS. This is difficult because the composition happens on a different thread and there are no good sync points. We can certainly do much better then this.

Comment 22

[Kartikaya Gupta (email:[e-mail])]

(In reply to Chris Lord [:cwiiis] from comment #20)
> Does the patch on bug 819183 fix it?

I created a try build with that patch at [1]. Tony, can you try using the APK at [2] to see if it fixes the problem? It will show up as "Nightly" in your android app screen. I believe your device is an ARMv7 device but in case it's an ARMv6 device you can use the build at [3] instead.

[1] https://tbpl.mozilla.org/?tree=Try&rev=52e0125d7ed1
[2] http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-52e0125d7ed1/try-android/fennec-22.0a1.en-US.android-arm.apk
[3] http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-52e0125d7ed1/try-android-armv6/fennec-22.0a1.en-US.android-arm-armv6.apk

(In reply to Benoit Girard (:BenWa) from comment #21)
> The problem is when the surface size changes the compositor needs to paint
> the right frame with the right size and from my experience this tend to
> depend between preICS/ICS. This is difficult because the composition happens
> on a different thread and there are no good sync points. We can certainly do
> much better then this.

I don't understand why there are no good sync points. We do synchronous resume calls on the compositor from the java UI thread with the new surface size so it seems to me that we should be able to do this without any problem. Also it seems like if this were the problem then it would fix itself after a short period of time or while scrolling, but it remains in this bad state.

Comment 23

[Tony Green]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #22)

> I created a try build with that patch at [1]. Tony, can you try using the
> APK at [2] to see if it fixes the problem? It will show up as "Nightly" in
> your android app screen.

Success! That's working just right.

Good work! And many thanks for giving me a usable browser.

Comment 24

[Kartikaya Gupta (email:[e-mail])]

Marking this as a dupe of bug 819183 based on comment 23. I see now that there are other dupes of this bug (also duped to bug 819183) from other people. We should really get that patch landed.