Closed Bug 920890 Opened 11 years ago Closed 11 years ago

App occasionally becomes white after several open/close action quickly.

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:koi+, b2g-v1.2 fixed)

RESOLVED FIXED
blocking-b2g koi+
Tracking Status
b2g-v1.2 --- fixed

People

(Reporter: alive, Assigned: alive)

References

Details

(Whiteboard: [FT:System-Platform], burirun2)

Attachments

(2 files)

STR:
1. Open any app
2. Press home button

Repeat several times.

Actual:
The app becomes all white.

Still don't know what happens but doesn't look like a visibility issue.
isn't this related to the problem you mentioned in bug 919048? Same root cause?
No, it's the whole app becomes white, but maybe the same root cause. Not a visibility issue because touch event is not passed to the app.
blocking-b2g: --- → koi?
I think visibility is correctly set from gaia side. Trying to build gecko to see if frameLoader.visible is correctly set, too.
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: true; src=app://homescreen.gaiamobile.org/index.html#root
I/Gecko   ( 1229): BrowserElementParent.jsm - _childVisibilityChange(true)
I/Gecko   ( 1229): BrowserElementParent.jsm - fireEventFromMsg: visibilitychange, {"visible":true,"msg_name":"visibilitychange"}
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: true; src=app://homescreen.gaiamobile.org/index.html#root
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: true; src=app://communications.gaiamobile.org/dialer/index.html#keyboard-view
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: false; src=app://homescreen.gaiamobile.org/index.html#root
I/Gecko   ( 1229): BrowserElementParent.jsm - _childVisibilityChange(false)
I/Gecko   ( 1229): BrowserElementParent.jsm - fireEventFromMsg: visibilitychange, {"visible":false,"msg_name":"visibilitychange"}
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: false; src=app://homescreen.gaiamobile.org/index.html#root
I/Gecko   ( 1229): BrowserElementParent.jsm - _childVisibilityChange(true)
I/Gecko   ( 1229): BrowserElementParent.jsm - fireEventFromMsg: visibilitychange, {"visible":true,"msg_name":"visibilitychange"}
I/Gecko   ( 1229): BrowserElementParent.jsm - Successful gotDOMRequestResult.
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: false; src=app://communications.gaiamobile.org/dialer/index.html#keyboard-view
I/Gecko   ( 1229): BrowserElementParent.jsm - _childVisibilityChange(false)
I/Gecko   ( 1229): BrowserElementParent.jsm - fireEventFromMsg: visibilitychange, {"visible":false,"msg_name":"visibilitychange"}
I/Gecko   ( 1229): BrowserElementParent.jsm - Successful gotDOMRequestResult.
I/Gecko   ( 1229): BrowserElementParent.jsm - frameLoader visible: false; src=app://communications.gaiamobile.org/dialer/index.html#keyboard-view

Looks like app://communications.gaiamobile.org/dialer/index.html#keyboard-view is set visible = false two times :(
OK, windowClosed is executed after openWindow so visibility is set to false.
I think this might be caused by latency of getScreenshot callback :(
Whiteboard: [FT:System-Platform]
I remove the getScreenshot call because of race condition and it seems we don't need to catch screenshot anymore. Card view would capture screenshot on demand.
Attachment #810945 - Flags: review?(timdream)
TRIAGE: this should be koi+ without doubt. Nearly 100% reproduce rate.
Also this patch seems resolve bug 919048 as well.
Blocks: 919048
blocking-b2g: koi? → koi+
Attachment #810945 - Flags: review?(timdream) → review+
(In reply to Alive Kuo [:alive] from comment #7)
> Created attachment 810945 [details]
> https://github.com/mozilla-b2g/gaia/pull/12488
> 
> I remove the getScreenshot call because of race condition and it seems we
> don't need to catch screenshot anymore. Card view would capture screenshot
> on demand.

This code was not to capture a screenshot but to avoid a flicker effect when the application is transitioned to the card view. The current patch will likely regress that. I wonder if we can't simply check the state of the application in this case before calling setVisible(false)  instead?
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #9)
> (In reply to Alive Kuo [:alive] from comment #7)
> > Created attachment 810945 [details]
> > https://github.com/mozilla-b2g/gaia/pull/12488
> > 
> > I remove the getScreenshot call because of race condition and it seems we
> > don't need to catch screenshot anymore. Card view would capture screenshot
> > on demand.
> 
> This code was not to capture a screenshot but to avoid a flicker effect when
> the application is transitioned to the card view. The current patch will
> likely regress that. I wonder if we can't simply check the state of the
> application in this case before calling setVisible(false)  instead?

I propose that capture the screenshot on appwillclose event when homebutton is long pressed. Thought?
I don't want to introduce another buggy state check here in window manager...
Proposed change:
In cardview's holdhome event listener, request a screenshot from current appWindow by appWindow.getScreent()
and do the following in the callback function.
I know this may slow down the holdhome action but maybe we could reduce the hold timing to avoid that.
I think in the original design we're taking screenshot even we don't need it if we never use cardview and screenshot takes time.
Uh, the screenshotting only happens on current displayed app in card view :/
But it's still strange that we capture screenshot each time we close an app.

Trying to capture upon app closing..
WIP
https://github.com/alivedise/gaia/compare/bugzilla;920890_master_v2;getscreenshot-delay?expand=1

Vivien, I do think current logic in master couldn't prevent flicking...
Reason:

Holdhome -> Display Homescreen -> CloseWindow -> getScreenshot ->  traverse runningApps -> put cahced screenshot ->  getScreenshot for lastDiaplayedApp --async--> having screenshotURL
                                                       |--async---> having screenshotURL


I think we cannot guarantee first callback is executed before getting the cached screenshot in cardview.
Attached file 920890_v2.patch
V2: Catching screenshot before holdhome handler is executed.

Please note the app may be flicking when openning from cardview but this is not a regression as it also happens in master now. I will try to check this issue later.

I introduce two new public methods to WindowManager but I may remove them later.
Attachment #811087 - Flags: review?(21)
Blocks: 919785
Blocks: 919789
Comment on attachment 811087 [details]
920890_v2.patch

As you say fixing flicking when the app comes into view is a different bug but that is a must have imo to make the OS feels nice. Can you file a followup?
Attachment #811087 - Flags: review?(21) → review+
(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #17)
> Comment on attachment 811087 [details]
> 920890_v2.patch
> 
> As you say fixing flicking when the app comes into view is a different bug
> but that is a must have imo to make the OS feels nice. Can you file a
> followup?

Sure, but that seems like a graphic issue now to me.
Blocks: 922546
No longer blocks: 922546
No longer blocks: 919789
No longer blocks: 919048
No longer blocks: 919785
This isn't a smoketest blocker - it doesn't block any of the target smoketests defined right now. This is however, still a bad bug that we should get fixed.
Keywords: smoketest
Travis is green
https://travis-ci.org/mozilla-b2g/gaia/builds/12034927

Megred during summit!
https://github.com/mozilla-b2g/gaia/commit/c9090021f7d642bae1db73a1093ab3dbb5078642
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
I was not able to uplift this bug to v1.2.  If this bug has dependencies which are not marked in this bug, please comment on this bug.  If this bug depends on patches that aren't approved for v1.2, we need to re-evaluate the approval.  Otherwise, if this is just a merge conflict, you might be able to resolve it with:

  git checkout v1.2
  git cherry-pick -x -m1 c9090021f7d642bae1db73a1093ab3dbb5078642
  <RESOLVE MERGE CONFLICTS>
  git commit
Flags: needinfo?(alive)
The issue reproduces on the latest Buri 1.2 Aurora MOZ RIL,
During the test run, a white screen appears when opening an email from "Contact" and then opening the "email" app

BuildID 20131010004001
Gaia   51f3c79ea93bb91d3b12e50b49d203a049a94a9b
SourceStamp 3f16dc100b1f
Version 26.0a2US_
Firmware revision: 20130912
Whiteboard: [FT:System-Platform] → [FT:System-Platform], burirun2
Blocks: 925609
No longer blocks: task-manager
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: