Closed
Bug 920890
Opened 10 years ago
Closed 10 years ago
App occasionally becomes white after several open/close action quickly.
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
Tracking
(blocking-b2g:koi+, 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.
Comment 1•10 years ago
|
||
isn't this related to the problem you mentioned in bug 919048? Same root cause?
Assignee | ||
Comment 2•10 years ago
|
||
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.
Assignee | ||
Updated•10 years ago
|
blocking-b2g: --- → koi?
Assignee | ||
Comment 3•10 years ago
|
||
I think visibility is correctly set from gaia side. Trying to build gecko to see if frameLoader.visible is correctly set, too.
Assignee | ||
Comment 4•10 years ago
|
||
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 :(
Assignee | ||
Comment 5•10 years ago
|
||
OK, windowClosed is executed after openWindow so visibility is set to false. I think this might be caused by latency of getScreenshot callback :(
Updated•10 years ago
|
Whiteboard: [FT:System-Platform]
Assignee | ||
Comment 7•10 years ago
|
||
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)
Assignee | ||
Comment 8•10 years ago
|
||
TRIAGE: this should be koi+ without doubt. Nearly 100% reproduce rate. Also this patch seems resolve bug 919048 as well.
Blocks: 919048
Updated•10 years ago
|
blocking-b2g: koi? → koi+
Updated•10 years ago
|
Attachment #810945 -
Flags: review?(timdream) → review+
Comment 9•10 years ago
|
||
(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?
Assignee | ||
Comment 11•10 years ago
|
||
(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...
Assignee | ||
Comment 12•10 years ago
|
||
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.
Assignee | ||
Comment 13•10 years ago
|
||
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..
Assignee | ||
Comment 14•10 years ago
|
||
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.
Assignee | ||
Comment 15•10 years ago
|
||
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)
Comment 16•10 years ago
|
||
Is this a duplicate of bug 912961?
Comment 17•10 years ago
|
||
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+
Assignee | ||
Comment 18•10 years ago
|
||
(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.
Assignee | ||
Comment 19•10 years ago
|
||
filed bug 922546 re-running travis https://travis-ci.org/mozilla-b2g/gaia/builds/12000403
Assignee | ||
Comment 23•10 years ago
|
||
Fixing travis https://travis-ci.org/mozilla-b2g/gaia/builds/12034927
Comment 28•10 years ago
|
||
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
Assignee | ||
Comment 29•10 years ago
|
||
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: 10 years ago
Resolution: --- → FIXED
Comment 30•10 years ago
|
||
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)
Comment 31•10 years ago
|
||
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
Assignee | ||
Comment 32•10 years ago
|
||
v1.2 https://github.com/mozilla-b2g/gaia/commit/79abf09f2b5b6440f43cb5ae44ef6c85c0437e8d
status-b2g-v1.2:
--- → fixed
Flags: needinfo?(alive)
Assignee | ||
Updated•10 years ago
|
Blocks: task-manager
Assignee | ||
Updated•10 years ago
|
No longer blocks: task-manager
You need to log in
before you can comment on or make changes to this bug.
Description
•