601367 - Black screen flicker when virtual keyboard opens and closes in awesome screen

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

Mozilla/5.0 (Android; Linux armv7l; rv:2.0b7pre) Gecko/20100102 Firefox/4.0b7pre Fennec/4.0b2pre
 
Essentially, every time I visit the Awesome Screen and tap the location bar, the screen will flicker black as the virtual keyboard appears.

Using a Motorola Milestone with 2.2.1 and IMEI (3583360301051600) Motorola Keyboard

Comment 1

[Aakash Desai [:aakashd]]

We should update our software keyboard testcases if this is fixed.

Comment 2

[Aaron Train [:aaronmt]]

There is also a black flicker (taking up the dimensions of the virtual keyboard) when the virtual keyboard closes.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

As per comment 2, I can repro by:
1) placing the device in portrait view
2) going to google.com
3) click in the text field to bring up VKB
4) open a side panel

Comment 4

[Michael Wu [:mwu]]

The flickering should be largely fixed by bug 599397. The black area left when the keyboard resizes, however, is still there. Morph/close/open new bug as necessary.

Comment 5

[Aaron Train [:aaronmt]]

(In reply to comment #4)
> The flickering should be largely fixed by bug 599397. The black area left when
> the keyboard resizes, however, is still there. Morph/close/open new bug as
> necessary.

Confirming that with bug 599397 landing this issue persists.

Comment 6

[Brian Crowder]

I can not reproduce this.  Is anyone else still seeing this?

Comment 7

[Aaron Train [:aaronmt]]

Every time the virtual keyboard opens up and drops in Fennec on my Milestone

Comment 8

[Brian Crowder]

The Android browser actually does this same graphical behavior, only the background they draw over the "unowned" area after the resize is white, rather than black.

Comment 9

[Brian Crowder]

mwu is going to own this, hacking the drawing code to issue white (or, as discussed on IRC for a future enhancement, using the background color of the top-level element on-screen).

Comment 10

[Michael Wu [:mwu]]

Attachment: Always draw white and do syncDraws more reliably

This makes the drawing code even more paranoid about locking the canvas unnecessarily, and improves the reliability of sync draws. It also adds a bunch of comments about locking in the drawing path.

Comment 11

[Michael Wu [:mwu]]

http://hg.mozilla.org/mozilla-central/rev/65b8060f0ea9

Comment 12

[Aaron Train [:aaronmt]]

Michael, some clarification? While I can safely say I see no more black flicker, I still see flicker albeit the drawing code as you mentioned and what I see is white. From what I see this is still more visible on Fennec than the Android Browser. 

Tested on a Motorola Milestone and Nexus One device.

Comment 13

[Michael Wu [:mwu]]

(In reply to comment #12)
> Michael, some clarification? While I can safely say I see no more black
> flicker, I still see flicker albeit the drawing code as you mentioned and what
> I see is white. From what I see this is still more visible on Fennec than the
> Android Browser. 
> 
> Tested on a Motorola Milestone and Nexus One device.

If the flicker of white is within the keyboard region, it is as expected. If there is a flash of white within the non-keyboard region, it isn't expected.

Comment 14

[Michael Wu [:mwu]]

I just noticed an interesting trick that the default browser does - it clears the entire screen to white before showing the url completion popup. I'll file a bug for doing that trick in our frontend.

Comment 15

[Aakash Desai [:aakashd]]

verified FIXED on builds:
Mozilla/5.0 (Android; Linux armv71; rv:2.0b8pre) Gecko/20101111 Namoroka/4.0b8pre Fennec/4.0b3pre

Comment 16

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=13837
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=13838