845661 - [Browser] Attention screens don't appear when the browser app's URL bar is focused

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia, defect)

Description

[Leo]

1. Title : Alarm is not shown
2. Precondition : Set an alarm.
3. Tester's Action :
                   1) Open any page in browser 
                   2) click on the url bar and wait for the alarm to go on.
                   3) It is observed that only alarm sound is heard. the alarm UI is not visible

4. Detailed Symptom (ENG.) : It is observed that only alarm sound is heard. the alarm UI is not 

visible
5. Gaia Version : 6916e18d1f72936e892543cf4a104a7d457f78ad
6. Expected : Alarm UI should be shown.
7.Reproducibility: Y
1)Frequency Rate : 100%

Comment 1

[Leo]

This only happens when 'Browser' is added to outOfProcessBlackList array. It seems there is an issue when opening a new window from an app belonging to the outOfProcessBlackList array in window_manager.js

Repo steps:
1. Launch the alarm app and set the alarm to one minute later.
2. Launch Browser app and touch the address bar.
3. Let the keyboard open and wait until the alarm goes off.

Comment 2

[Leo]

It seems that Justin is an expert on this. Justin, Would you be able to take this bug?

Comment 3

[Justin Lebar (not reading bugmail)]

Hi, Leo.  It's actually considered a bit presumptuous to assign a bug to someone, particularly if you're not their manager.  We use bug assignment to indicate that someone is actively working on a bug, so letting people arbitrarily assign bugs to other people would be pretty confusing.

> This only happens when 'Browser' is added to outOfProcessBlackList array.

To be clear, 'Browser' is part of outOfProcessBlackList by default, right?

This sounds to me like a bug in the Gaia window manager, which is not my area of expertise.  It would probably be helpful if you could include the output from |adb logcat|; it's possible that we're hitting something that's causing the window manager to throw an exception which would be reported there.

Comment 4

[Leo]

Hi Justin, 

I'm sorry about that. But I had no options, it wasn't my decision to do so.. :( I will  inform my people around about that. 

Thanks.

Comment 5

[Leo]

Same issue exists when there is an incoming call when a user is using the browser app. This seems critical.

Comment 6

[[e-mail], [e-mail]]

Looks like a critical issue, I take care of it.

Comment 7

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

To clarify the 2 situations that Ian discovered,

1. Before commit 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
  the attention screen could be shown for the first time, but not for 2nd+ time.
  Note this only occurs for browser app, could not be reproduced with other apps  

2. After that patch 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
the attention screen would not be shown every time per the bug description.


If we reverted one the changes in 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
Change the following line, https://github.com/mozilla-b2g/gaia/blob/a186001c3f21181026c686b6aec611feb2ac9fb2/apps/system/js/attention_screen.js#L54

back to
  this.attentionScreen.style.height = window.innerHeight + 'px';

Then, for the first time, the attention screen could be shown.
Still not sure why that change makes any difference.

Comment 8

[[e-mail], [e-mail]]

(In reply to Rudy Lu [:rudyl] from comment #7)
> To clarify the 2 situations that Ian discovered,
> 
> 1. Before commit 19f1a8f91a624cca07d018b8ad1154d013eb24b6,
>   the attention screen could be shown for the first time, but not for 2nd+
> time.
>   Note this only occurs for browser app, could not be reproduced with other
> apps  
For the attention screen could not be shown for 2nd+ time, I find out it's relative with blur app frame. We could reference the commit (a27ca826bf2948ec6342a0f365c384adb48d2fcb). The patch is supported for hiding keyboard while attention screen is showing. If we remove blur app frame, attention screen will work normally. I still have no idea about the root cause.

BTW, is it relative with OOP? Per Rudy's experiment, if we let Browser app be OOP(or let all apps not in OOP), all of the above issues cannot be reproduces. Does someone have any idea?

Comment 9

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Hi all,

Here is an update on the investigation.

1. This issue will occur when the app to show attention screen is not in the same process of the current process with keyboard.
   a. Dialer (OOP) + Browser (in-process) => can reproduce, and this is the case in bug description.
      Dialer (OOP) + Calendar (in-process, modified for testing) => can reproduce

   b. Dialer (OOP) + Browser (OOP, for testing only) => OK
      Dialer (OOP) + Calendar (OOP) => OK

   c. Move all app. in process
      Dialer (in-process) + Browser (in-process) => OK

So, this should be an OOP related issue.

--
Thanks to SC on the investigation support.

Comment 10

[[e-mail], [e-mail]]

Thanks for Rudy and SC's help. Obviously it's an OOP issue. It may need dev who is relative with OOP to handle it.

Comment 11

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

I wonder how gecko would fix this issue...
Couldn't we find a gaia workaround?

Comment 12

[[e-mail], [e-mail]]

It's hard to have a workaround for avoided the two issues. BTW, I try to blur the iframe with setTimeout 0s. The attention screen could be showing, but not hide the keyboard. The situation only occurs in Browser app too.

Comment 13

[Andrew Overholt [:overholt]]

David, can you find someone to work on this?  As Alive says, it would be nice to work around this in gaia.  But Ian thinks that might not be possible ...

Comment 14

[Justin Lebar (not reading bugmail)]

It is not clear to me what the putative Gecko bug is, other than "an OOP issue".  If there's an actual bug here, we should fix it.  But someone needs to dig in.

Comment 15

[Dale Harvey (:daleharvey)]

Looking into this, so far the only differing log output when we fail to show the attention screen is 

I/Gecko   ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko   ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko   ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko   ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503
I/Gecko   ( 1536): [Parent 1536] WARNING: throttled animations not up to date: '!CommonAnimationManager::ThrottlingEnabled() || mPresContext->ThrottledStyleIsUpToDate()', file /Volumes/Boot2Gecko/B2G/gecko/layout/style/nsTransitionManager.cpp, line 503

Comment 16

[Andrew Overholt [:overholt]]

Should we ask dbaron about the layout log entries?

Comment 17

[Dale Harvey (:daleharvey)]

nah at this point I am fairly sure its a gaia bug, trying to narrow it down is tricky but should hopefully have it tonight

Comment 18

[Andrew Overholt [:overholt]]

Are things still going alright here, Dale?  If you're too overloaded we could try to find someone to take it over from you.

Comment 19

[Dale Harvey (:daleharvey)]

Yeh sorry, I keep getting side tracked but I have time to find this now, not guaranteed tomorrow but definitely before monday

Comment 20

[isabelrios]

Hi, 

This has been also detected during certification in Spain with ikura. 

Adding dep to meta bugs.

Comment 21

[Dale Harvey (:daleharvey)]

Sorry still working on this, I think it is a z-index problem with stacked in and out of process iframes, trying to make a small test case to reproduce but I keep going down the wrong rabbit hole.

Comment 22

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I have a workaround that let it works. I'm not proud of it and it workaround the gecko issue but that should be fine for now. I will post it a bit later.

Comment 23

[Dale Harvey (:daleharvey)]

Did you nail down the actual gecko issue?

Comment 24

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Workaround

Here the workaround.

Comment 25

[Dale Harvey (:daleharvey)]

This workaround looks stable to me, I havent been able to reproduce the bug with it applied.

I am having a hard time tracking down the root bug, it doesnt seem to be just a missing repaint, If I trigger another repaint after a timeout it still doesnt become visible and as far as I can tell the attention screen is in the dom and styled exactly as it should be. There were various workarounds involving settimeouts for the keyboard but viviens is cleaner than anything I came up with.

I think this should be landed, vingetun?

Comment 26

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Dale Harvey (:daleharvey) from comment #25)
> This workaround looks stable to me, I havent been able to reproduce the bug
> with it applied.
> 
> I am having a hard time tracking down the root bug, it doesnt seem to be
> just a missing repaint, If I trigger another repaint after a timeout it
> still doesnt become visible and as far as I can tell the attention screen is
> in the dom and styled exactly as it should be. There were various
> workarounds involving settimeouts for the keyboard but viviens is cleaner
> than anything I came up with.
> 
> I think this should be landed, vingetun?

I think the main issue is: something very expensive happens on the main process/thread and expose a race condition in the layout/gfx code. When this expensive operation stops, the app is not repainted but if you force it to be resize (by hitting the home button for example) then it repaints.

Let's use this workaround right now but I would love a new bug to track the platform issue (which is not OOP related since it happens only if the browser application is in-process and so have the priority of the main process).

I think the main issue is something very heavy happens on the main process and it is

Comment 27

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Let's steal it for now.

Comment 28

[Dale Harvey (:daleharvey)]

Comment on attachment 736254 [details] [diff] [review]
Workaround

Tested this as much as I can, havent been able to reproduce a similiar bug, I filed a bug for platform (https://bugzilla.mozilla.org/show_bug.cgi?id=861799)

Comment 29

[Dale Harvey (:daleharvey)]

Merged in: https://github.com/mozilla-b2g/gaia/commit/558effceb97a172cd1e6a306d25fbb1484d8c19c

Comment 30

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

Uplifted commit 558effceb97a172cd1e6a306d25fbb1484d8c19c as:
v1-train: 8c8d831f6e3371e526e91c443688ff600dc82dfe
v1.0.1: b63ebb468031e741072b9bc99eec86a76ff9b6de

Comment 31

[Carlos Martínez Toral [:carlosmartinez]]

Verified fixed on inari device with:

Gaia   e6d694f86e6a704fce00509de7c65aa976ade9f6
BuildID 20130418004045
Version 18.0

Comment 32

[John Hammink]

Seems to be working on the certification target, 4/26 partner build for Ikura.

Comment 33

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

The contentWindow to check OOP state here seems failed:
Now for every active app, the visibility will be soon turned off.