To prevented recording unwanted sound the camera has to stop recording video when an incoming call arrives or when an alarm is triggered. The camera stops when is sent to background on response to the visibilitychange event. This should be enough to pause recording before callscreen runs and the ringtone starts playing. I observed that the visibilitychange events are delivered in an order that prevents an application to perform an action before being sent to background and before a new app takes over the foreground. Below is the sequence of calls when an incoming call is received while the camera is open in the foreground. Callscreen is notified of being on the foreground before the camera knows that has been sent to background. E/GeckoConsole( 3346): Content JS LOG at app://callscreen.gaiamobile.org/js/calls_handler.js:73 in onCallsChanged: E/GeckoConsole( 3346): Content JS LOG at app://callscreen.gaiamobile.org/js/index.js:12 in visibilitychanged: E/GeckoConsole( 3346): Content JS LOG at app://callscreen.gaiamobile.org/js/calls_handler.js:73 in onCallsChanged: E/GeckoConsole( 3451): Content JS LOG at app://camera.gaiamobile.org/js/main.js:6601 in App.prototype.onVisibilityChange:

Blocks a cert blocker.

Seems like a window management issue?

There is a 3 sec delay for attention screens -- we cannot toggle the visibility change before the transition of the attention screen is completed otherwise user will see a flash of white. It was there since 1.0. Suggest WONTFIX, or dup to bug 927862 (where the behavior will be changed based on the new window management.) (In reply to Jason Smith [:jsmith] from comment #1) > Blocks a cert blocker. What the basis of blocking decision here? Call screen app mentioned in comment 0 is a 1.3T/master feature, it does not exist in 1.3.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #3) > There is a 3 sec delay for attention screens -- we cannot toggle the > visibility change before the transition of the attention screen is completed > otherwise user will see a flash of white. It was there since 1.0. Suggest > WONTFIX, or dup to bug 927862 (where the behavior will be changed based on > the new window management.) Diego - Can you weigh in here if you are agreement with this? We'll have to find another way to fix bug 995540. > > (In reply to Jason Smith [:jsmith] from comment #1) > > Blocks a cert blocker. > > What the basis of blocking decision here? Call screen app mentioned in > comment 0 is a 1.3T/master feature, it does not exist in 1.3. TCL has deemed the blocking bug here as a certification blocker for the release.

This is a bit tricky. If we can not change the ordering of events we will probably need to implement a new event that is sent before the visibilitychange event. Augmenting the page visibility API[1] to have some new event like 'willhide' seems like the correct approach - though it's unlikely this will make 1.3t. [1] https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API

We need to know from camera when the app is going to background as soon as possible? The 3 seconds delay is not acceptable for us. The only way we have to know that there's an app switch is the visibilitychange event. We need to stop video recording from camera before a ringtone or an alarm sound start playing or we will record sound in the video. Is it possible to have a different event: visibilitywillchange, appisgoingtobackground... I can see other use cases where apps would like to make sure that shut down properly before any other app performs any action. There might be even security and privacy concerns for some scenarios.

In fact the current scenario already introduces privacy issues since we record 3+ plus seconds of video and sound after an app switching. The user is going to assume that the app has closed.

Setting this back to 1.3+ based on comment 4. Although I don't know why they come back to us on this 1.0 behavior. (In reply to Kevin Grandon :kgrandon from comment #5) > ... - though it's > unlikely this will make 1.3t. I assume you meant to say 1.3. I think the doable hack, for 1.3, would be have the Camera app to listen to callschange event. (In reply to Diego Marcos [:dmarcos] from comment #6) Alive can provide more info on this I think.

What about alarms? What about any other events that might send camera to background?

Attention screen is only used by phone calls, alarms, and bluetooth pairing request dialog. For 1.3, which is a release branch, we should aim for a solution that comes with smallest set of changes, so I would say we can just unblock the cert requirement by probing phone calls only.

No. The cert blocking bug refers to alarms too. It's exactly the same problem than phone calls.

Did you mean to set 1.3+ here instead of 1.3T+?

(In reply to Jason Smith [:jsmith] from comment #12) > Did you mean to set 1.3+ here instead of 1.3T+? Sorry, too much Tarako bugs ... (In reply to Diego Marcos [:dmarcos] from comment #11) > No. The cert blocking bug refers to alarms too. It's exactly the same > problem than phone calls. OK. Actually, reading bug 995540 comment 12 I am a bit confused. My understanding is that this has always been the behavior of System app, but somehow according to you System app 2 months ago does not have this behavior. Do we want to bisect and see which commit on the v1.3 branch "break" this?

Comment #12 is a misunderstanding of the bug on my side. I had been able to reproduce the problem on that version too. Updating bug 995540 for the record.

There's lot of bugs duped like this bug in bug attention-window. If this bug is really a blocker we need to introduce some hacks before it's implemented. And for sure there's no opportunity to fix it in pre-v1.4. Suggestion: drop the rendering (by setVisible(false)) anyway and send the app to background immediately on attention screen shown. Please note there will be bugs as "white screen is shown when call comes" will be fired...

(In reply to Diego Marcos [:dmarcos] from comment #7) > In fact the current scenario already introduces privacy issues since we > record 3+ plus seconds of video and sound after an app switching. The user > is going to assume that the app has closed. No "app switch" but only attention screen will cause this. What makes you think this?

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #15) > There's lot of bugs duped like this bug in bug attention-window. If this bug > is really a blocker we need to introduce some hacks before it's implemented. > And for sure there's no opportunity to fix it in pre-v1.4. > > Suggestion: drop the rendering (by setVisible(false)) anyway and send the > app to background immediately on attention screen shown. Please note there > will be bugs as "white screen is shown when call comes" will be fired... Another proposal: switch to the app opens the attention screen right away. But callscreen change makes this tough...

If camera listens for onCallsChanged. Is there an equivalent event for alarms?

Seems like we might be able to fire an IAC message from the system app to the camera when the attention window is about to show? This way the camera app can listen to the IAC event and stop recording before the attention screen is shown. Seems like it should be able to work for calls or alarms?

This is a copy of my comment in the parent bug. It would be a really ugly hack, but could we fix this by setting the camera audio stream priority to be as high as the telephony and alarm priority when the camera is recording a video? Then, when the visibility change arrives and we're sent to the background we stop recording, release our audio priority and the telephone or alarm ringer starts playing... I don't know if that would work since I don't really understand the audio priority stuff, but a workaround like that seems more plausible for a late 1.3+ bug than a change to the system app.

Needinfo Dominic because he knows all about the audio competing policy. Dominic: do you think what I describe above could be used to solve bug 995540?

(In reply to David Flanagan [:djf] from comment #20) > This is a copy of my comment in the parent bug. > > It would be a really ugly hack, but could we fix this by setting the camera > audio stream priority to be as high as the telephony and alarm priority when > the camera is recording a video? Then, when the visibility change arrives > and we're sent to the background we stop recording, release our audio > priority and the telephone or alarm ringer starts playing... > > I don't know if that would work since I don't really understand the audio > priority stuff, but a workaround like that seems more plausible for a late > 1.3+ bug than a change to the system app. I am afraid the policy is hardcoded in gecko so we cannot fix it in gaia... We plan to move the policy decision to gaia but it's beyond 2.0 (In reply to Diego Marcos [:dmarcos] from comment #18) > If camera listens for onCallsChanged. Is there an equivalent event for > alarms? Not, unless camera have alarm permission/system message to do stuff like this. I suggest to use IAC to fix this as Kevin mentioned. Proposal: when camera launches, post message to system app to keep the connection opened and when system app knows attention screen comes, post message back to camera to stop recording.

(In reply to David Flanagan [:djf] from comment #20) > This is a copy of my comment in the parent bug. > > It would be a really ugly hack, but could we fix this by setting the camera > audio stream priority to be as high as the telephony and alarm priority when > the camera is recording a video? Then, when the visibility change arrives > and we're sent to the background we stop recording, release our audio > priority and the telephone or alarm ringer starts playing... > > I don't know if that would work since I don't really understand the audio > priority stuff, but a workaround like that seems more plausible for a late > 1.3+ bug than a change to the system app. I think probably could not work here because when the incoming call rings, both system and camera are visible(foreground), and the ringer sound is in system app(dialer_agent.js), so even we try to add a higher/equal priority channel with silent sound in camera, I guess the audio competing policy will still let the ringer play before the camera's visibility change. But maybe it could fix the alarm case, cause if we set the camera's silent channel to "ringer", then alarm channel won't be heard(bug 871467 can prove this though it's a telephony > alarm/notification case) unless the camera's visibility changed then stop the higher channel. I would suggest not to do this hack because the |public notification| and |ringer| types seems the only two could be higher/equal than the incoming call or alarm's channels, imagine that we will always have a silent sound playing with publicnotification/ringer type channel in camera, which will let the audio competing policy think there is a active publicnotification/ringer and won't allow the background content channel, like music app to play, it means we cannot use the camera and listen to the background music at the same time. The possible solution for these two cases could be: 1. (Incoming call) - Put the ringer(dialer_agent.js) into an iframe in system app, also set visibility to it(like the window management) then it should follow the audio competing policy. I would be very happy to see this happen because, although the ringer plays in system, it should be treated as a mini app in charge of playing ringtones, not part of the system logic which already broken the audio ux we tried very hard to keep, and potentially it will fix many audio competing issues. 2. (Alarm) - Play the alarm tone after the alarm's window is visible, I am not sure what's the timing visibility will change, but in theory this is achievable and make more sense that, the alarm window does show and the alarm tone plays. IAC could be an alternative solution but for me, there will be a bunch of IAC code that just to fix this issue, in both system and alarm.

(In reply to Dominic Kuo [:dkuo] from comment #23) > The possible solution for these two cases could be: > > 1. (Incoming call) - Put the ringer(dialer_agent.js) into an iframe in > system app, also set visibility to it(like the window management) then it > should follow the audio competing policy. I would be very happy to see this > happen because, although the ringer plays in system, it should be treated as > a mini app in charge of playing ringtones, not part of the system logic > which already broken the audio ux we tried very hard to keep, and > potentially it will fix many audio competing issues. I found I was wrong about the visibility change in system app(thanks Alive!). One iframe will inherit its parent's visibility, so in system app, even we put the ringer in one iframe and change its visibility to hidden, it will always be visible because system app is visible, so this approach won't work. > 2. (Alarm) - Play the alarm tone after the alarm's window is visible, I am > not sure what's the timing visibility will change, but in theory this is > achievable and make more sense that, the alarm window does show and the > alarm tone plays. After the alarm window is inserted to the dom tree, the visibility will become visible immediately so my assumption is incorrect. This won't work, too. Could we try to delay the ringtone or alarmtone base on duration of the attention screen transition? though it's still a ugly hack...

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #22) > (In reply to David Flanagan [:djf] from comment #20) > > This is a copy of my comment in the parent bug. > > > > It would be a really ugly hack, but could we fix this by setting the camera > > audio stream priority to be as high as the telephony and alarm priority when > > the camera is recording a video? Then, when the visibility change arrives > > and we're sent to the background we stop recording, release our audio > > priority and the telephone or alarm ringer starts playing... > > > > I don't know if that would work since I don't really understand the audio > > priority stuff, but a workaround like that seems more plausible for a late > > 1.3+ bug than a change to the system app. > > I am afraid the policy is hardcoded in gecko so we cannot fix it in gaia... > We plan to move the policy decision to gaia but it's beyond 2.0 > > > (In reply to Diego Marcos [:dmarcos] from comment #18) > > If camera listens for onCallsChanged. Is there an equivalent event for > > alarms? > > Not, unless camera have alarm permission/system message to do stuff like > this. > > I suggest to use IAC to fix this as Kevin mentioned. > > Proposal: when camera launches, post message to system app to keep the > connection opened and when system app knows attention screen comes, post > message back to camera to stop recording. Alive/Tim, We don't seem to have a viable solution that just involves changes to camera. Do we have other alternatives? Implementing IAC based notifications is very late for 1.3 -- though some kind of notification mechanism that would let camera know when to stop recording is probably the way to go. We need your team's help here to get this cert blocker addressed for 1.3 Thanks Hema

If we are discussing about IAC, we might as well as hack the Settings DB again. How's that? The code in the system app attention screen can be as simple as // XXX: tell the apps we have an attention screen going on. // Remove this hack after bug XXXXXX navigator.mozSettings.createLock().set({ 'attentionscreen.status': 'show' });

David has already do it in https://bugzilla.mozilla.org/show_bug.cgi?id=995540

I landed my patch using a setting hack for 1.3 only in bug 995540. Now we need to figure out what to do for 1.4 and master. I've converted this bug from 1.3+ to 1.4+ so we can use it for followup. Alive: in your review for bug 995540 you said you weren't sure about landing the setting hack in any release beyond 1.3. What should we do instead? Use IAC? Is there some other way to send messages from the system app to other apps? Shouldn't the system app be able to do a postMessage() to child apps? That might not be any less of a hack, though. Perhaps we should actually try to define a WebAPI for the type of notification we need. Games might want to use the notification to automatically pause instead of waiting for the visibility change event.

Carrying over regression keyword as the end user behavior regresses now between 1.3 & 1.4.

(In reply to David Flanagan [:djf] from comment #28) > I landed my patch using a setting hack for 1.3 only in bug 995540. > > Now we need to figure out what to do for 1.4 and master. I've converted this > bug from 1.3+ to 1.4+ so we can use it for followup. > > Alive: in your review for bug 995540 you said you weren't sure about landing > the setting hack in any release beyond 1.3. What should we do instead? Use > IAC? Is there some other way to send messages from the system app to other > apps? Shouldn't the system app be able to do a postMessage() to child apps? > That might not be any less of a hack, though. No postMessage because security restrict. Even we could we still can't because this is not standard. > > Perhaps we should actually try to define a WebAPI for the type of > notification we need. Games might want to use the notification to > automatically pause instead of waiting for the visibility change event. All of this comes from a improper attention screen design. I think we could fix this in 1.5/2.0 but for 1.4 I am really not sure what's the effort.

Should we merge the workaround in the camera app for 1.4 & re-evaluate this for 2.0?

(In reply to Jason Smith [:jsmith] from comment #31) > Should we merge the workaround in the camera app for 1.4 & re-evaluate this > for 2.0? I think so. David, would you be able to downlift your patch in bug 995540 to 1.4?

Tim: yes, it should be easy to get the patch into 1.4. The camera refactor is probably the only thing that prevents the patch from applying directly. Diego: do you have time to take this and produce a version of the 1.3 patch for the 1.4 camera?

Hi Diego, any feedback for Comment 33 ? Thanks.

Throwing this to Camera again since as of comment 32 we are still looking at doing workaround for 1.4. Please clone a bug to System::Window Mgmt if bug 927862 is not enough.

Diego or Wilson, Can one of you take this up? Thanks Hema

This one is not something that we can fix on the camera side. djf came up with a workaround on bug 995540. The patch had landed for 1.3 and I attached a PR for 1.4 (bug 995540). The root of the issue described in this bug has to addressed in the system app for 1.4+. Any ETA for the fix of this bug for 1.4+?

(In reply to Diego Marcos [:dmarcos] from comment #37) > This one is not something that we can fix on the camera side. djf came up > with a workaround on bug 995540. The patch had landed for 1.3 and I attached > a PR for 1.4 (bug 995540). The root of the issue described in this bug has > to addressed in the system app for 1.4+. > > Any ETA for the fix of this bug for 1.4+? Thanks for the update. According to previous comment from Tim, he was under the impression that the PR for 1.4 is being worked on as part of this bug. But you clarified it, so putting this back into system app. Thanks Hema

I don't despite the fact the root cause lies on the window management side, I simply want to make sure for 1.4 we should still (sadly) do workaround. It looks like we are doing that exactly for 1.4, but in bug 995540 comment 29 instead. That makes this bug fall out of 1.4+ bucket. I am flagging this as 2.0? so we can decide what to do with 2.0 later.

(BTW, s/despite/dispute/ on comment 39) This bug is considered a regression from bug 995540 since 1.4 if we don't fix it in 2.0. Alive, what's your proposed fix in the 2.0 schedule? Judging by the progress in bug 927862 I don't think we will be able to make it ....

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #40) > (BTW, s/despite/dispute/ on comment 39) > > This bug is considered a regression from bug 995540 since 1.4 if we don't > fix it in 2.0. Alive, what's your proposed fix in the 2.0 schedule? Judging > by the progress in bug 927862 I don't think we will be able to make it .... Unfortunately I am overloaded to make bug 927862 happens before feature freeze, and it's too risky in stabilization phase, so the only way is awaiting vivien's fix on gecko to keep the rendering or take the same workaround to 2.0....

Vivien, what is your "keep the rendering" bug and it is targeting 2.0?

https://bugzilla.mozilla.org/show_bug.cgi?id=1002430 should be

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #42) > Vivien, what is your "keep the rendering" bug and it is targeting 2.0? What Alive links. I would be more than happy to land that for 2.0. My understanding is that one of the remaining issue is related to resources beeing allocated on the gpu that should force us to release some layers. As of today there is no such messages in Gecko that tells us to do that :/

Per a drivers' discussion - this isn't going to block. bug 995540 needs to land as a permanent workaround to this issue.

Why is this not going to block? We need a reliable mechanism to know when an app goes to background so it can properly shutdown. This has security and privacy implications and must block 2.0. In the case of the camera we were recording video for a few seconds without the user being aware of it. It this bug is not we have to evaluate every app and implement workarounds for any of them. Also it brings risks for 3rd party apps.

Tim, can you please help understand if the team can fix this priority bug by FL(June 9th) keeping comment# 46 in mind? Diego, explains how his hack works only for the camera app in : https://bugzilla.mozilla.org/show_bug.cgi?id=1006200#c46, but it could still be an issue for other apps(1st and 3rd party).

Discussed this with Diego on vidyo with bbajaj. If we were out of time for the release, then we would take the camera workaround & live with this bug, since we've shipped with this problem previously with the workaround applied. We do believe that this is a high-priority non-blocker, so we should look into getting this fixed.

IMHO we should still consider workaround for 2.0 to take this issue off 2.0+ queue, and make this bug remain to be a known issue to developers.

(In reply to bhavana bajaj [:bajaj] from comment #47) > Tim, can you please help understand if the team can fix this priority bug by > FL(June 9th) keeping comment# 46 in mind? This feature was not a 2.0 priority. The regression (the absent of the workaround in Camera app) is. I can talk to the team to make this a feature-b2g: 2.1 priority if we feel this is an outstanding issue to all apps. That also means the product team need to make sure the other feature-b2g: 2.1 priorities are in their right orders compare to this one. No surprises. > Diego, explains how his hack works > only for the camera app in : > https://bugzilla.mozilla.org/show_bug.cgi?id=1006200#c46, but it could still > be an issue for other apps(1st and 3rd party). This impacts 3rd-party developers because your Angry Birds will not know there is a phone call for 5 sec after it has been covered by the call screen, and birds will die during that time.

It's not a regression in Camera it's a regression in the platform. To avoid a screen flashing you decided to not deliver the visibilitychange event to the application going to background until the application going to foreground takes over. That's a hack. And now you are asking me to implement a hack to work around of yours. The hack implemented in camera for 1.3 / 1.4 abuses the settings API to detect an attention screen opening (code below). It makes me really sad that we cannot solve this properly. navigator.mozSettings.createLock().set({ 'private.broadcast.attention_screen_opening': true }); (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #50) > (In reply to bhavana bajaj [:bajaj] from comment #47) > > Tim, can you please help understand if the team can fix this priority bug by > > FL(June 9th) keeping comment# 46 in mind? > > This feature was not a 2.0 priority. The regression (the absent of the > workaround in Camera app) is. I can talk to the team to make this a > feature-b2g: 2.1 priority if we feel this is an outstanding issue to all > apps. That also means the product team need to make sure the other > feature-b2g: 2.1 priorities are in their right orders compare to this one. > No surprises. > > > Diego, explains how his hack works > > only for the camera app in : > > https://bugzilla.mozilla.org/show_bug.cgi?id=1006200#c46, but it could still > > be an issue for other apps(1st and 3rd party). > > This impacts 3rd-party developers because your Angry Birds will not know > there is a phone call for 5 sec after it has been covered by the call > screen, and birds will die during that time.

(In reply to Diego Marcos [:dmarcos] from comment #51) > It's not a regression in Camera it's a regression in the platform. Regression from which version? This has always been a known issue. > To avoid > a screen flashing you decided to not deliver the visibilitychange event to > the application going to background until the application going to > foreground takes over. That's a hack. And now you are asking me to implement > a hack to work around of yours. The hack implemented in camera for 1.3 / 1.4 > abuses the settings API to detect an attention screen opening (code below). > It makes me really sad that we cannot solve this properly. > > navigator.mozSettings.createLock().set({ > 'private.broadcast.attention_screen_opening': true > }); > Trust me, I am no more happier than you on this situation. Now, do we have a mutual understand on how we can make this still work on 2.0 release?

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #52) > (In reply to Diego Marcos [:dmarcos] from comment #51) > > It's not a regression in Camera it's a regression in the platform. > > Regression from which version? This has always been a known issue. Exactly the same for camera. Regression from which version? Recording video while receiving an incoming call has never worked properly. We just were not aware of it until has been reported. The way to fix this in a less hacky and not camera-recording-video specific way would be adding an event "willvisibilitychange" so applications have an opportunity to perform actions before any other app takes over. How complicated is doing that? An extra event would not have any impact on any app not using it. > > > To avoid > > a screen flashing you decided to not deliver the visibilitychange event to > > the application going to background until the application going to > > foreground takes over. That's a hack. And now you are asking me to implement > > a hack to work around of yours. The hack implemented in camera for 1.3 / 1.4 > > abuses the settings API to detect an attention screen opening (code below). > > It makes me really sad that we cannot solve this properly. > > > > navigator.mozSettings.createLock().set({ > > 'private.broadcast.attention_screen_opening': true > > }); > > > > Trust me, I am no more happier than you on this situation. > > Now, do we have a mutual understand on how we can make this still work on > 2.0 release?

(In reply to Diego Marcos [:dmarcos] from comment #53) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #52) > > (In reply to Diego Marcos [:dmarcos] from comment #51) > > > It's not a regression in Camera it's a regression in the platform. > > > > Regression from which version? This has always been a known issue. > > Exactly the same for camera. Regression from which version? Recording video > while receiving an incoming call has never worked properly. We just were not > aware of it until has been reported. I don't understand what you are trying to say here. We usually mark a bug blocking because we realized some feature released on a previous version broke on the current version. That's the definition of regression. In the case here, the window management never properly worked since 1.0, hence the pre-load apps need to workaround until it does. > The way to fix this in a less hacky and not camera-recording-video specific > way would be adding an event "willvisibilitychange" so applications have an > opportunity to perform actions before any other app takes over. How > complicated is doing that? An extra event would not have any impact on any > app not using it. > That's a non-trivial fix on Gecko mozbrowser API and the event has little value than workaround this window management issue.

You have said that the window management behavior has been around since 1.0 and admitted that it is a hack. How this has not been addressed or prioritized to be properly implemented? It is not acceptable piling up hacks and accumulate technical debt specially on such fundamental things. What's the ETA for this issue to be properly fixed? Who's going to fix it? If I'm going to implement a hack on top of your hack I want an ETA for the fix of the root issue. I'm going to double circle it on red on my calendar.

I am not sure if you understand how feature-b2g: 2.1 is decided in this project; it's not entirely decided by developers even if you shoot at me. I will surely sound my opinion on prioritizing bug 927862 so we could address it as soon as possible. I am very uncomfortable and frustrated when my colleague cannot speak to others with respect. Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html section 1 point 2 and 3.

I'm sorry if I come as blunt or harsh but sometimes I fear that people stop caring about fixing things. My goal is just shaking things up and bring some sense of urgency. I think we need it if we want to have a chance in the hyper competitive mobile space. I count on you too to also call me out if I do something shitty.

Clearing the nom as :jsmith mentioned we have the workaround in 2.0, NI Bruce to help prioritize this for 2.1 from product standpoint.

This should block 2.1. This has implications for all the apps 1st and 3rd party. For instance, this bug makes firefox OS useless for gaming. In case of an incoming call when playing a game, the game will keep playing for a few seconds and the user has no control over it anymore.

Another implication: https://bugzilla.mozilla.org/show_bug.cgi?id=1037880

Tim, Can you comment on prioritization of this as a manifestation of this is reported here in 1051172 and we should fix the core issue in 2.1 ?

Once bug 927862 we are deprecating all 3sec delays. That means all what we could do from gaia side is finished. If people still think the application should be notified once it's closing or another application is opening, please push the platform issue https://bugzilla.mozilla.org/show_bug.cgi?id=1034001 to happen.