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

RESOLVED FIXED in Firefox OS v1.1hd

Status

Firefox OS
Gaia::System
--
critical
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Leo, Assigned: alive)

Tracking

unspecified
1.1 QE2 (6jun)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:leo+, b2g18+ fixed, b2g-v1.1hd fixed)

Details

(Whiteboard: [TD-25991] [TD-23399] [TD-23477] MiniWW)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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:  hanj.kim25@gmail.com

This is a regression from Bug 856546.
(Reporter)

Comment 1

5 years ago
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;
(Reporter)

Updated

5 years ago
See Also: → bug 856546, bug 871374
(Reporter)

Updated

5 years ago
Severity: normal → critical
Whiteboard: [TD-25991]

Updated

5 years ago
Target Milestone: --- → 1.1 QE2

Comment 2

5 years ago
Same blocking status as bug 869903, since it's a very similar problem.
blocking-b2g: --- → -
tracking-b2g18: --- → +
Assignee: nobody → alive
(Reporter)

Comment 3

5 years ago
I tested with latest v1-train now and I still see the white screen problem when phonecall ends.
(Reporter)

Comment 4

5 years ago
(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.
(Reporter)

Comment 5

5 years ago
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)
Attachment #753162 - Flags: feedback?(alive)
(Reporter)

Updated

5 years ago
See Also: → bug 869903
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.
(Reporter)

Comment 7

5 years ago
(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
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...
(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.
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 ;)
(Reporter)

Comment 11

5 years ago
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?
Attachment #753686 - Flags: feedback?(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?
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.
(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.)
Attachment #753686 - Flags: feedback?(alive)
Attachment #753162 - Flags: feedback?(alive)
(Reporter)

Updated

5 years ago
blocking-b2g: - → leo?
(Reporter)

Updated

5 years ago
Whiteboard: [TD-25991] → [TD-25991] [TD-23399] [TD-23477]

Updated

5 years ago
blocking-b2g: leo? → leo+
(Reporter)

Comment 15

4 years ago
As discussed in San Diego, marking this for work week.
Whiteboard: [TD-25991] [TD-23399] [TD-23477] → [TD-25991] [TD-23399] [TD-23477] MiniWW

Comment 16

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

Updated

4 years ago
Flags: needinfo?(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.
Flags: needinfo?(alive)

Comment 18

4 years ago
Thanks 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.

Updated

4 years ago
Assignee: alive → mwu

Comment 20

4 years ago
Created attachment 756305 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/10121

Pointer to Github pull-request

Updated

4 years ago
Attachment #756305 - Flags: review?(21)
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?
Attachment #756305 - Flags: review?(21) → review-
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

4 years ago
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.
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.
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?
Flags: needinfo?(justin.lebar+bug)
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.
(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.
> 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.
Flags: needinfo?(justin.lebar+bug)
> 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...
(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?
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

4 years ago
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.
(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

4 years ago
Created attachment 758337 [details] [diff] [review]
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.
Attachment #756305 - Attachment is obsolete: true
Attachment #758337 - Flags: feedback?(alive)

Comment 35

4 years ago
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 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.
Attachment #758337 - Flags: feedback?(alive) → feedback+

Comment 37

4 years ago
(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.
(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...
Assignee: mwu → alive

Comment 39

4 years ago
(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.
Created attachment 758391 [details]
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.
Attachment #758391 - Flags: review?(timdream)
Working on some design modification now.
Comment on attachment 758391 [details]
https://github.com/mozilla-b2g/gaia/pull/10200

This is a good start for the WindowManager partition plan.
Attachment #758391 - Flags: review?(timdream) → review+
Blocks: 845251
master
https://github.com/mozilla-b2g/gaia/commit/807e5af901b05e87b9f5aaebe0ba97e40ce9b54f
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g18: --- → affected
Resolution: --- → FIXED
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
Flags: needinfo?(alive)
v1-train
https://github.com/mozilla-b2g/gaia/commit/c8ea9299a4a8a96f361d3e4adf3798698c6bd096
status-b2g18: affected → fixed
Flags: needinfo?(alive)
1.1hd: c8ea9299a4a8a96f361d3e4adf3798698c6bd096
status-b2g-v1.1hd: --- → fixed

Updated

4 years ago
Duplicate of this bug: 825174
Uh...I don't think bug 825174 is a dupe of this :/
You need to log in before you can comment on or make changes to this bug.