871919 - [System] White screen is displayed shortly after phonecall ends.

Status: RESOLVED FIXED

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

Description

[Leo]

1. Title : [System] White screen is displayed shortly after phonecall ends.
2. Precondition : Call 1st phone from 2nd phone.
3. Tester's Action : End the phonecall on 1st phone.
4. Detailed Symptom (ENG.) : Observe white screen displayed shortly after dial app is closed.
5. Expected : No white screen inbetween should be displayed.
6.Reproducibility: Y
           1)Frequency Rate : 100%
7.Gaia Master/v1-train : Reproduced
8.Gaia Revision: 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c
9.Personal email id:  [e-mail]

This is a regression from Bug 856546.

Comment 1

[Leo]

For testing purpose only, if I revert the following change from the Bug 856546 patch in window_manager.js, it does not happen.

        case 'attentionscreenshow':
        var detail = evt.detail;
        if (detail && detail.origin && detail.origin != displayedApp) {
          attentionScreenTimer = setTimeout(function setVisibility() {
            if (inlineActivityFrames.length) {
              setVisibilityForInlineActivity(false);
            } else {
              setVisibilityForCurrentApp(false);
            }
          }, 3000);

          // Instantly blur the frame in order to ensure hiding the keyboard
          var app = runningApps[displayedApp];
          if (app) {
            if ('contentWindow' in app.iframe) {
              // Bug 845661 - Attention screen does not appears when
              // the url bar input is focused.
              // Calling app.iframe.blur() on an in-process window
              // seems to triggers heavy tasks that froze the main
              // process for a while and seems to expose a gecko
              // repaint issue.
              // So since the only in-process frame is the browser app
              // let's switch it's visibility as soon as possible when
              // there is an attention screen and delegate the
              // responsibility to blur the possible focused elements
              // itself.
              app.iframe.setVisible(false);
            } else {
              app.iframe.blur();
            }
          }
        }
        break;

Comment 2

[Alex Keybl [:akeybl]]

Same blocking status as bug 869903, since it's a very similar problem.

Comment 3

[Leo]

I tested with latest v1-train now and I still see the white screen problem when phonecall ends.

Comment 4

[Leo]

(In reply to Leo from comment #0)
> 2. Precondition : Call 1st phone from 2nd phone.

Adding precondition:

2. Precondition :
   1) Run any app (e.g. Clock) except homescreen, browser, dialer.
   2) Call 1st phone from 2nd phone.

Comment 5

[Leo]

Attachment: Repro steps

Hi Alive, 

This is a recording with yesterday's v1-train (2013.05.22, probably same in your timezone as well.)

I still see the white screen when phonecall ends. Also I still see the white screen shortly when incoming call prompts. (which I have mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=871374#c20)

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

I recall that I explain the call end case in some comments...but anyway.
Yes I know this is reproducible.

The root cause of call begin issue may be the set visibility timer is failed by some reason,
and I don't see white screen iff it's at homescreen(will show wallpaper), if you're using some other app other than homeescreen you will see the white screen temporarily.

Comment 7

[Leo]

(In reply to Alive Kuo [:alive] from comment #6)
> I recall that I explain the call end case in some comments...but anyway.
> Yes I know this is reproducible.
> 
> The root cause of call begin issue may be the set visibility timer is failed
> by some reason,
> and I don't see white screen iff it's at homescreen(will show wallpaper), if
> you're using some other app other than homeescreen you will see the white
> screen temporarily.

Are you talking about the clearTimeout call, which is mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=871413#c1 ?

Any idea when the fix will be ready?

Thanks

Comment 8

[(inactive after 6/18) Alive Kuo [:alive]]

I just try again on v1-train and the code looks well.
I mean the timer doesn't fail.

I guess there's a time difference happens some where.

You could try to write an app and observe the timing of visibilitychange event you recieved in the app when it is covered by callscreen.

IMO the white screen is really fast and so doesn't seem to be a blocking bug.
Sorry for being late, but as I say this seems not an important bug.

Some ppl is complaining that when call comes, the app under the attention screen should be "immediately" brought to background.

This request and yours is conflicting, what I could do is only modify the 3000ms timer up and down.

Sorry, no idea, because this is an UX decision and as a dev, I think we should show the call screen immediately to run out of these white screen bugs...

Comment 9

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Leo from comment #5)
> Created attachment 753162 [details]
> Repro steps
> 
> Hi Alive, 
> 
> This is a recording with yesterday's v1-train (2013.05.22, probably same in
> your timezone as well.)
> 
> I still see the white screen when phonecall ends. Also I still see the white
> screen shortly when incoming call prompts. (which I have mentioned in
> https://bugzilla.mozilla.org/show_bug.cgi?id=871374#c20)

I just do a video recording about what I see,
1) I don't see the white screen when call comes.
2) Yes there's a white screen before callscreen slideup transition ends.

I will upload the video soon.

Comment 10

[(inactive after 6/18) Alive Kuo [:alive]]

https://bugzilla.mozilla.org/show_bug.cgi?id=875254 
I file this for dialer bug, please I expect to be rejected by UX decision reason ;)

Comment 11

[Leo]

Attachment: Why Usage app is started on incoming call

Hi Alive, 

One thing weird is that, after incoming call is received, 'Usage' app is in the cardview. And it's pure white. Is this related to this bug?

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Leo from comment #11)
> Created attachment 753686 [details]
> Why Usage app is started on incoming call
> 
> Hi Alive, 
> 
> One thing weird is that, after incoming call is received, 'Usage' app is in
> the cardview. And it's pure white. Is this related to this bug?

Another bug I believe :( Open new one?

Comment 13

[Jinho Hwang [:jeffhwang]]

Hi Alive, 

I check this bug can be solved using attchment 749180 
and change window_manager.js a little bit.

The cause why the white screen appears shortly is explained in bug 825174 #43.
And I'm waiting fot feedbacks.

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to JinhoHwang from comment #13)
> Hi Alive, 
> 
> I check this bug can be solved using attchment 749180 
> and change window_manager.js a little bit.
> 
> The cause why the white screen appears shortly is explained in bug 825174
> #43.
> And I'm waiting fot feedbacks.

Good to hear somebody is taking action from gecko side!
(But I don't see attachment 749180 [details] [diff] [review] changes anything in gaia.)

Comment 15

[Leo]

As discussed in San Diego, marking this for work week.

Comment 16

[Andreas Gal :gal]

Whats the action here? This was marked blocking. Alive are you working on this?

Comment 17

[(inactive after 6/18) Alive Kuo [:alive]]

OK so I am going to try to fix bug 875254 as a short term fix of this bug.
It looks like the gecko fix wouldn't be in time.

Comment 18

[Andreas Gal :gal]

Thanks alive.

Comment 19

[(inactive after 6/18) Alive Kuo [:alive]]

I remove the callscreen closing transition in dialer/js/oncall.js and there's still a timing difference between |setVisible=true| and the iframe really paints.

So I have 2 proposal here:
1. Delay the attentionscreen close function until timeout or WindowManager tells it the next paint happens.
   Side effect 1: all attention screen will have the same delay on closing.
   Side effect 2: the next paint event is not guaranteed to be fired in time(300ms).
2. Take a screenshot during the iframe is invisible and paste it until system app notices the iframe's visibility is changed(mozbrowservisibilitychange event in bug 868816). With this we don't need to remove the callscreen closing transition, at least for now.

After discussion w/ Tim we're going to do 2. now.

Comment 20

[Michael Wu [:mwu]]

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10121

Pointer to Github pull-request

Comment 21

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 756305 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10121

Unwanted power consumption and audio competing will be broken by this change,
why do you think this works?

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

The patch at least will regress https://bugzilla.mozilla.org/show_bug.cgi?id=853454
and lots of problems as the app is dealing with mozvisibilitychange event.

If someone tells you that we could tolerate all this happens, please inform me. thanks.

Comment 23

[Michael Wu [:mwu]]

Could you elaborate on the audio issues you would expect from this patch? Some light testing hasn't revealed any issues, but please let me know if there's specific test cases I should be aware of.

As for power consumption, bug 853454 indicated that this was an issue with the app's visibility not being set to false when the screen is turned off. This patch does not affect that code and the app should continue to be set invisible when the screen turns off.

Comment 24

[(inactive after 6/18) Alive Kuo [:alive]]

I paste the wrong bug number. sorry. But I couldn't find it now.
A confidential bug talks about when during call the app under callscreen should stop updating UI because this consumes more power. The example is music. It listens to timeupdate event to update the thumb position. It shouldn't update UI because it's invisibile.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

My WIP before bug is stolen:

https://github.com/alivedise/gaia/commits/screenshot-layer_master
Retain the screenshot layer on app window before the next paint event happens.
The only problem now is the screenshot of homescreen is not transparent because it's jpg not png. Tim suggests open a bug for enhance the getScreenshot mozbrowser API to adopt one more argument to indicate PNG or JPG.

Now since bug is stolen, it's fine. But I definitely don't think we should give up page visibility controlling during attention screen shows. Too bad to memory/power.
We make lots efforts on controlling the visibility state in window manager to have a reasonable state now, we shouldn't abandon it.

The code still also doesn't make sense because you should remove attentionscreenshow/attentionscreenhide/statusbar-active/statusbar-inactive in overlay event listener to reflect that you don't care those events fire from the attentionscreen module. Remove all un-used codes. Keep the remaining code works.

Justin, how do you think?

Comment 26

[Jinho Hwang [:jeffhwang]]

I think Alive intented to mention about Bug 856546. Because of this bug, Window Manager need to call setvisibility(false) on attentionscreenshow.

Michael, the reason why we can just ignore to change the visibility for the foreground application is same with that why we couln't apply the patch attachment 740707 [details] [diff] [review] for Bug 862913.

I guess the best way to solve this problem is what we are discussiong on Bug 825174, do not clear caches for the foreground document which is displayed on the screen currently.

Comment 27

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to JinhoHwang from comment #26)
> I think Alive intented to mention about Bug 856546. Because of this bug,
> Window Manager need to call setvisibility(false) on attentionscreenshow.
> 
> Michael, the reason why we can just ignore to change the visibility for the
> foreground application is same with that why we couln't apply the patch
> attachment 740707 [details] [diff] [review] for Bug 862913.
> 
> I guess the best way to solve this problem is what we are discussiong on Bug
> 825174, do not clear caches for the foreground document which is displayed
> on the screen currently.

Hi, (leo.gecko?),
I am not familiar with gecko/gonk enough, so is bug 862913 is to keep the last "snapshot" of the mozbrowser iframe after we setVisible(false) to it? If so I do nearly the same thing but in gaia level here as comment 19, comment 22 said. But if gecko supports this its really awesome.

Comment 28

[Justin Lebar (not reading bugmail)]

> But I definitely don't think we should give up page visibility controlling during 
> attention screen shows. Too bad to memory/power. We make lots efforts on controlling the 
> visibility state in window manager to have a reasonable state now, we shouldn't abandon 
> it.

Yeah, I agree.

> [This branch]
> https://github.com/alivedise/gaia/commits/screenshot-layer_master
> retains the screenshot layer [of an] app window before the next paint event happens.
> The only problem now is the screenshot of homescreen is not transparent because it's jpg 
> not png. Tim suggests open a bug for enhance the getScreenshot mozbrowser API to adopt 
> one more argument to indicate PNG or JPG.

Its not a big deal to change the API to let you have PNG or JPEG, but can you elaborate on why that's necessary?  Note also that a transparent lossless PNG will likely take up a lot more memory than a JPEG.

Comment 29

[Justin Lebar (not reading bugmail)]

> My proposal in bug 871919 is: fetch the screenshot and cover it above the mozbrowser 
> iframe when the attentionscreen enter/leave event happening. I don't know if this is too 
> expensive.

Okay, I understand now.

Merely taking a screenshot can take a few hundred ms.  And I think in b2g18, you're not going to get images displayed in that screenshot (bug 846177).  This doesn't seem like a great solution to me...

Comment 30

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Justin Lebar [:jlebar] from comment #29)
> > My proposal in bug 871919 is: fetch the screenshot and cover it above the mozbrowser 
> > iframe when the attentionscreen enter/leave event happening. I don't know if this is too 
> > expensive.
> 
> Okay, I understand now.
> 
> Merely taking a screenshot can take a few hundred ms.  And I think in b2g18,
> you're not going to get images displayed in that screenshot (bug 846177). 
> This doesn't seem like a great solution to me...

Uh, I think bug 846177 has be fixed or partially fixed..at least I see correct header of settings app in card view in recent build....maybe just because they change the background image.

It's not a perfect one but the only thing I could do from gaia now.
An inaccurate image is better than just having a white screen.
But...fine. So do you think bug 825174 would save all of us from the white screen?

Comment 31

[Justin Lebar (not reading bugmail)]

AIUI we're getting a white screen because the app that we're trying to show is just one big image, and that one image hasn't been decoded yet.  So I don't think taking a screenshot would help.  If it does help, we can talk about it...

> So do you think bug 825174 would save all of us from the white screen?

I think so...

Comment 32

[Michael Wu [:mwu]]

Poked around a bit more and discovered the reason why we see the empty iframe underneath while animating the call screen up. The oncall screen does its own animation after ending a call and then closes itself. The window manager/attention screen code can't show the underlying app until it receives mozbrowserclose, but mozbrowserclose happens after the animation is done.

Comment 33

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Michael Wu [:mwu] from comment #32)
> Poked around a bit more and discovered the reason why we see the empty
> iframe underneath while animating the call screen up. The oncall screen does
> its own animation after ending a call and then closes itself. The window
> manager/attention screen code can't show the underlying app until it
> receives mozbrowserclose, but mozbrowserclose happens after the animation is
> done.

See my comments before, I'd specified all what you said here... PLEASE READ THANKS.
I don't want to change the UX spec here. And it also doesn't help if the callscreen transition is removed.

(In reply to Justin Lebar [:jlebar] from comment #31)
> AIUI we're getting a white screen because the app that we're trying to show
> is just one big image, and that one image hasn't been decoded yet.  So I
> don't think taking a screenshot would help.  If it does help, we can talk
> about it...


You could try to apply https://github.com/alivedise/gaia/commits/screenshot-layer_master
see the effect is terrible or ok.

Comment 34

[Michael Wu [:mwu]]

Attachment: Wait a second to close the attention screen

Try this patch. It disables the animation and waits a second before closing the attention screen. I tried to wait on the next paint but that didn't seem to work.

Comment 35

[Michael Wu [:mwu]]

The animation disabling is just a hack to see if waiting a second to close would work. I'm sure there's better ways to get rid of the animation there.

Comment 36

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 758337 [details] [diff] [review]
Wait a second to close the attention screen

The direction isn't bad, but the correct way should be wait for a next-paint event from active app window as what I do in my WIP.

Comment 37

[Michael Wu [:mwu]]

(In reply to Alive Kuo [:alive] from comment #36)
> Comment on attachment 758337 [details] [diff] [review]
> Wait a second to close the attention screen
> 
> The direction isn't bad, but the correct way should be wait for a next-paint
> event from active app window as what I do in my WIP.

Feel free to take the bug back if you can get the next paint event to work.

Comment 38

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Michael Wu [:mwu] from comment #37)
> Feel free to take the bug back if you can get the next paint event to work.

Thanks. Let's do some workaround in gaia first before people come up with a perfect solution in bug 862913...

Comment 39

[Michael Wu [:mwu]]

(In reply to Alive Kuo [:alive] from comment #38)
> (In reply to Michael Wu [:mwu] from comment #37)
> > Feel free to take the bug back if you can get the next paint event to work.
> 
> Thanks. Let's do some workaround in gaia first before people come up with a
> perfect solution in bug 862913...

Bug 862913 is a different issue related to the image cache getting thrown out, but that doesn't happen on as much now. This issue is about how long it takes for mozbrowser iframes to come up once they're visible.

Comment 40

[(inactive after 6/18) Alive Kuo [:alive]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/10200

Patch proposal:
1. Create a screenshot layer in app window
2. Skip homescreen screenshot(commented in app window)

Tested with lots app all works fine.

Comment 41

[(inactive after 6/18) Alive Kuo [:alive]]

Working on some design modification now.

Comment 42

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Comment on attachment 758391 [details]
https://github.com/mozilla-b2g/gaia/pull/10200

This is a good start for the WindowManager partition plan.

Comment 43

[(inactive after 6/18) Alive Kuo [:alive]]

master
https://github.com/mozilla-b2g/gaia/commit/807e5af901b05e87b9f5aaebe0ba97e40ce9b54f

Comment 44

[John Ford [:jhford] CET/CEST Berlin Time]

I was not able to uplift this bug to v1-train.  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-train, 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-train
  git cherry-pick -x -m1 807e5af901b05e87b9f5aaebe0ba97e40ce9b54f
  <RESOLVE MERGE CONFLICTS>
  git commit

Comment 45

[(inactive after 6/18) Alive Kuo [:alive]]

v1-train
https://github.com/mozilla-b2g/gaia/commit/c8ea9299a4a8a96f361d3e4adf3798698c6bd096

Comment 46

[John Ford [:jhford] CET/CEST Berlin Time]

1.1hd: c8ea9299a4a8a96f361d3e4adf3798698c6bd096

Comment 48

[(inactive after 6/18) Alive Kuo [:alive]]

Uh...I don't think bug 825174 is a dupe of this :/