Closed Bug 942331 Opened 11 years ago Closed 11 years ago

screen goes black when entering text into trusted UI

Categories

(Firefox OS Graveyard :: Gaia, defect)

Product:
Firefox OS Graveyard
Component:
Gaia
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: edwong, Unassigned)

Details

original bug here: https://github.com/mozilla/persona/issues/4015 1. Sign in with Persona 2. Enter a mozilla.com email address 3. Delegates to mozilla's LDAP sign-in iframe 4. Screen goes black, apparently right when password field gets focus Note that it's not the Trusted UI (Persona's container) that goes black - it's the entire screen. So this can't be a Persona bug; it's affecting drawables outside of our iframe.
here's lolcat: D/wpa_supplicant( 385): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c D/wpa_supplicant( 385): nl80211: survey data missing! E/QCALOG ( 187): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent] E/QCALOG ( 187): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent] E/QCALOG ( 187): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent] E/memalloc( 140): /dev/pmem: No more pmem available E/msm7627a.gralloc( 140): gralloc failed err=Out of memory W/GraphicBufferAllocator( 140): alloc(320, 480, 1, 00000133, ...) failed -12 (Out of memory) E/memalloc( 140): /dev/pmem: No more pmem available E/msm7627a.gralloc( 140): gralloc failed err=Out of memory W/GraphicBufferAllocator( 140): alloc(320, 480, 1, 00000133, ...) failed -12 (Out of memory) D/wpa_supplicant( 385): RX ctrl_iface - hexdump(len=11): 53 49 47 4e 41 4c 5f 50 4f 4c 4c D/wpa_supplicant( 385): nl80211: survey data missing!
This line: E/msm7627a.gralloc( 140): gralloc failed err=Out of memory Means we've ran out of memory, so the screen going black happens as a result. What base image are you running?
We've repro'd on internal builds: 1 hamachi and 1 buri with nightly 1.2 eng build 1 inari with 1.3 nightly eng build.
I'm running this on a nightly hamachi build (22-Nov-2013) Alcatel OneTouch device with a 2GB MicroSD inside. b2g-info when signing into Evernav (after opening settings to enable remote debugging): | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 139 0 50.0 52.6 66.3 180.0 0 root Usage 389 18 11.8 13.9 26.7 65.9 10 app_389 Homescreen 397 1 14.0 16.3 29.7 74.9 2 app_397 Settings 468 18 15.2 17.5 30.9 70.5 10 app_468 Evernav 484 1 13.1 15.3 28.6 72.5 2 app_484 (Preallocated a 879 18 8.8 10.6 22.3 62.3 10 root Browser 919 1 13.9 16.2 29.5 82.2 2 app_919 System memory info: Total 180.4 MB Used - cache 143.8 MB B2G procs (PSS) 142.6 MB Non-B2G procs 1.2 MB Free + cache 36.6 MB Free 3.2 MB Cache 33.4 MB The 'Browser 919' process is the Trusted UI + Persona iframe. So are we getting OOM'd when the keyboard app gets summoned? Why doesn't Settings at least get swapped out? More information: When I reproduce this on a nightly hamachi build (22-Nov-2013 build), after what I suppose is the interval for the screensaver to take over, I can wake the phone up, pass the lock screen, and resume with the Trusted UI, where the password field is in focus. When I type, each keystroke causes the entire screen to flicker to black. After a few keystrokes, the screen remains black for a few seconds. The duration of the blackouts feels erratic, but they appear to be triggered by the keystrokes. So those apps are still there; they're not dead; and they're all trying to run. Is it just that the keyboard app keeps getting killed by the system?
I'm trying to test the facebook connect login alternative on Evernav. Unfortunately, if you create a new account on sign-in, you get trapped in facebook and there seems to be no way back to Evernav. Hrm.
Jed/Edwin - I need to know the base image you are using. This problem is an issue that happens on 1.1 base images with gaia/gecko commits flashed on top. This should not happen with a 1.2 base image with gaia/gecko flashed on top.
(In reply to Jason Smith [:jsmith] from comment #6) > Jed/Edwin - I need to know the base image you are using. This problem is an > issue that happens on 1.1 base images with gaia/gecko commits flashed on > top. This should not happen with a 1.2 base image with gaia/gecko flashed on > top. Ok, yes. I just got my hamachi, which arrived with a 1.1 base image. I flashed a Mozilla nightly build on top of it. I will work with QA to get a 1.2 base image (I don't have the tools to do this myself). Thanks, jsmith
Going to put qawanted to confirm what I'm thinking above: Can someone test comment 0 out on a 1.2 base image with the latest gaia/gecko commits? That will confirm that this is a base image problem.
Keywords: qawanted
Did not see this issue when signing in to persona on the latest 1.2 and 1.3 moz builds using a 1.2 base image on a buri device, after signing in to persona the screens progressed as expected and I did not encounter a black screen during the process. Are the specifics of Step 2 in the initial writeup critical to reproducing this issue? I used my own gmail.com email address to log in to persona and did not encounter the issue, rather than a mozilla.com email address. 1.2 Environmental Variables: Device: Buri v1.2 Mozilla RIL BuildID: 20131125004001 Gaia: c2dea53b36bb9d4331a94976344515f60dc5a3d4 Gecko: 368ea26d2136 Version: 26.0 Base Image: V1.2_20131115 1.3 Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20131125040208 Gaia: 9935ceb4fe96fff48e78b941cfd2a69d8639a418 Gecko: 250bb14d76d4 Version: 28.0a1 Base Image: V1.2_20131115
Keywords: qawanted
QA Contact: jzimbrick
I can't repro this anymore - might have been base image stuff. closing.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.