Build ID: Mozilla /5.0 (Android;Linux armv7l;rv:7.0a1) Gecko/20110617 Firefox/7.0a1 Fennec/7.0a1 Device: HTC Desire Z (Android 2.2) Steps to reproduce: 1. Load Fennec. 2. Tap the Home Button to bring the application in background. 3. Tap the application's icon. Actual results: White screen is displayed. Please see the video: http://www.youtube.com/user/qaioana#p/u/0/t-203zqNzOU Expected results: The webpage or about:home should be displayed.
Confirmed, I can see it in today's trunk build, but yesterday's build didn't have this problem.
Also happening when tapping on the 'Back' button while being in the options.
(In reply to comment #2) > Also happening when tapping on the 'Back' button while being in the options. I don't see this part. I _can_ see the white screen after tapping Home and coming back to the app. FWIW, tapping on the white screen causes a redraw and all is well again.
Regression from bug 661843
(In reply to comment #4) > Regression from bug 661843 Missed the "?" - That was a question, not a statement
I think it may be and I have a patch that possibly fixes it, just testing and will attach when it's done (if it does fix it...)
Created attachment 540059 [details] [diff] [review] Fix redraw-scheduling on first draw Because I'd altered the way surface creation works, it was possible to have a null buffer in surfaceChanged while having a valid surface size. Instead of looking at the buffer pointers, I've replaced it with a boolean that tracks whether the surface size is valid or not. This fixes the issue for me.
Now, after tapping Home and coming back to the app, I can see a black screen. Was the changeset pushed to the pushlog? Build ID:Mozilla /5.0 (Android;Linux armv7l;rv:7.0a1) Gecko/20110620 Firefox/7.0a1 Fennec/7.0a1 Device: HTC Desire Z (Android 2.2)
(In reply to comment #10) > Now, after tapping Home and coming back to the app, I can see a black > screen. Was the changeset pushed to the pushlog? I see the same on a Nexus One
Ok, I'll have to test this on my HTC Desire (works for me on the Xoom, but I guess that's quite different).
Not sure what's happened, but I can always reproduce this on my Xoom now... Wondering if something else has changed in the meantime. Looking at what happens, we create the surface fine, we get the surfaceChanged signal fine and we schedule the redraw fine - but the redraw doesn't happen. Am looking into this...
Typical, the real cause for this is a typo. Will attach a revised patch in a mo.
Created attachment 540939 [details] [diff] [review] Fix redraw handling on first draw after surfaceChanged Here's the udpated patch, along with a commit message. The typo was causing the synchronised draw scheduled in surfaceChanged to be ignored, so nothing was being painted at all.
Comment on attachment 540939 [details] [diff] [review] Fix redraw handling on first draw after surfaceChanged required followup to bug 661843 which is already m-a approved.
Verified Fixed Mozilla/5.0 (Android; Linux; armv7l; rv:7.0a1) Gecko/20110627 FIrefox/7.0a1 Fennec/7.0a1