959056 - [window manager][v1.3] FxOS will get black screen when app use |Web Activities| and then call |windose.close| immediately

Status: RESOLVED WONTFIX

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

Description

[GaryChen [:GaryChen][:PYChen][:gchen][:陳柏宇]]

** only in Gaia v1.3
Reproduce Steps:
--------------------------
1. apply patch: https://github.com/mozilla-b2g/gaia/commit/c1845bc43db6340d162034f8656e66a137ed1523#diff-cd37c4268e6090c519a90a8470efb0c2

2. Launch Settings
3. go to Keyboards -> Built-in keyboards, keyboard settings page appears
4. Tap on the backward button
   --> A black screen appears. User cannot do any operation.

Comment 2

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

Triage: +'ing, functional regression.

Comment 3

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

Correction: this is not a functional regression but a race in window manager introduced by certain operations of apps. Clearing flag.

Comment 4

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #3)
> Correction: this is not a functional regression but a race in window manager
> introduced by certain operations of apps. Clearing flag.

I'm not sure if that's right. I don't recall any of these problems showing up when we hit similar bugs like this in the past that would have triggered the black screen, but didn't (e.g. bug 946807 had a similar bug like it in past releases). The black screen trigger I've only seen happen in the 1.3 timeframe. The window manager often undergoes a lot of changes per each release, so I wouldn't be surprised if something regressed here. What's concerning here is we've seen this happen across two bugs so far, which leads to believe that there's a general problem here that could happen on the web.

I get the feeling there's a reduced test case here that could be triggered using a window activity with window.close being called within the context of the activity.

The severity here does warrant blocking however - this when triggers, completely renders the phone into a broken state. As such, I'm resetting the flags.

Comment 5

[Jason Smith [:jsmith]]

Put more generally - if you reproduce the same bug within a web content workflow more than once, that implies a general problem that can be triggered in third-party apps making use of web activities. We shouldn't ever end up a situation where the phone goes black, as that produces a terrible experience for a user making use of a third-party app that happens to trigger this web activity workflow in their code.

Comment 6

[Jason Smith [:jsmith]]

My theory of a reduced test case that could trigger this would probably something like:

1. In App A - trigger the MozActivity in App B in a window disposition
2. In App B - in the activity handler in App B, call window.close()
3. In App A - trigger the MozActivity in App B in a window disposition

Result - this would be the point where a black screen would be seen.

Comment 7

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

Your comment 5 is correct. This is indeed a general bug exists in pre-1.3 window manager code base.

However, your comment 5 and comment 4 are contradict to each other. Comment 4 describing this bug as a regression but comment 5 suggest otherwise. This bug is indeed NOT A REGRESSION. We shouldn't be blocking the bug based on that misjudgement.

For comment 5, I would say it make this bug not a blocker since no any 3rd-party app developers but us spot the problem. Obviously you have issues trusting your fellow developers, or just me, so I am setting this to 1.3? and have people look at it at the next triage.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #7)
> Your comment 5 is correct. This is indeed a general bug exists in pre-1.3
> window manager code base.
> 
> However, your comment 5 and comment 4 are contradict to each other. Comment
> 4 describing this bug as a regression but comment 5 suggest otherwise. This
> bug is indeed NOT A REGRESSION. We shouldn't be blocking the bug based on
> that misjudgement.

comment 5 isn't suggesting this isn't a regression. comment 5 is just confirming that can be triggered by web content. However, other instances of when this bug has similarly shown up in past releases did not show black screen regressions, where as 1.3 does. I think that clearly makes this is a regression. We could get a reduced test case to find out, but I think the evidence presented here is too weak to prove that this isn't a regression. Gary's comment in comment 0 even makes this suspicious for the fact that this is only being seen on 1.3.

> 
> For comment 5, I would say it make this bug not a blocker since no any
> 3rd-party app developers but us spot the problem. Obviously you have issues
> trusting your fellow developers, or just me, so I am setting this to 1.3?
> and have people look at it at the next triage.

That argument lacks data - third party app developers can do whatever they want when they build apps, which means that the error can be triggered. Any apparent risk that places the phone into a state that a black screen occurs is terrible, as that renders the phone useless. This is already happened twice in a row so far across two bugs, so I see this being a critical issue that must be resolved in the 1.3 timeframe.

Comment 9

[Jason Smith [:jsmith]]

It would be worth finding out also if this could be triggered from triggering an OOM on launch of the window activity, as that would quite realistic to happen in a third-party app, as many of third-party apps stress memory use of the phone.

Comment 10

[Jason Smith [:jsmith]]

Spoke w/Tim in person - what I think I'll do here is work on getting a reduced test case & then testing this on 1.1 to find out if this has existed previously or not.

Comment 11

[William Hsu [:whsu]]

A duplicate case of Bug 957906 or Bug 959116?

Comment 12

[Jason Smith [:jsmith]]

(In reply to William Hsu [:whsu] from comment #11)
> A duplicate case of Bug 957906 or Bug 959116?

Nope. This deals with the general problem in the window manager, not the specific cases that make use of the window manager through apps.

Comment 13

[BMO Automation]

Firefox OS is not being worked on