Closed Bug 1015073 Opened 7 years ago Closed 6 years ago

Gaia doesn't put the running app that occupies audiochannel in visibility background when the lockscreen shows up

Categories

(Firefox OS Graveyard :: AudioChannel, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(tracking-b2g:+, b2g-v1.4 affected, b2g-v2.0 affected, b2g-v2.0M affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED WORKSFORME
tracking-b2g +
Tracking Status
b2g-v1.4 --- affected
b2g-v2.0 --- affected
b2g-v2.0M --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: wang.xiao3, Unassigned)

References

Details

(Keywords: regression, sec-low, Whiteboard: [cert], permafail)

Attachments

(4 files)

Attached file skatejumper.7z
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 (Beta/Release)
Build ID: 20110413222027

Steps to reproduce:

1.open Marketplace application
2.search "skate Jumper",download and install
3.play the game of skate Jumper, then  lock screen


Actual results:

after above operation, the screen can not be unlocked.



Expected results:

after above operation, the screen can be unlocked.
blocking-b2g: --- → 1.3?
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
QA Wanted to see if we can reproduce on the latest 1.3 build.
Keywords: qawanted
QA,

Please check if this is reproducible
QA Contact: ddixon
Issue DOES occur in latest 1.3 Buri build. 

Environmental Variables:
Device: Buri
Build ID: 20140527083838
Gaia: 0ce948e378cab7ed3db20231281dd7ca2eb99779
Gecko: c8af9fdccab4
Version: 28.0 (1.3) MOZ
Firmware Version: v1.2device.cfg
Keywords: qawanted
Well, this seems bad if it's reproducible.

Vance - Is this a cert blocker?
Flags: needinfo?(vchen)
skate jumper is a 3rd party application, I don't think we can block on 3rd party application, right?

Thanks
Flags: needinfo?(vchen)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #5)
> skate jumper is a 3rd party application, I don't think we can block on 3rd
> party application, right?
> 
> Thanks

The root cause of the problem isn't a 3rd party issue - it's a problem with the lockscreen.
Thanks, this is a cert blocker
blocking-b2g: 1.3? → 1.3+
Whiteboard: [cert]
1.3+ for cert blocking
Whiteboard: [cert]
Kevin, please create a testcase from this bug for future branches.
Flags: in-moztrap?(ktucker)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [cert]
Test case created:

https://moztrap.mozilla.org/manage/case/13662/
Flags: in-moztrap?(ktucker) → in-moztrap+
Hi Greg, could you own this? Thanks.
Flags: needinfo?(gweng)
Is this the same with the Bug 1008486? The later one would occur because of the wrong orientation changing behavior. If the root cause is the same, this is a duplicated bug, and Gaia can't do efficient workaround (see the Bug 1008486).
Flags: needinfo?(gweng)
According to description in bug 1008486, this is because bug 868914 was broken by later builds. There are various discussion around orientation lock improvement, but first the current behavior cannot break.

Can we investigate what breaks bug 868914?
Component: Gaia::System::Lockscreen → General
Can we check if this happens on 1.1? That will tell us if we can do a window here to bisect this.
Keywords: qawanted
Issue DOES NOT occur in latest 1.1 Buri build

Environmental Variables:
Device: Buri 1.1
Build ID: 20140213041204
Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496
Gecko: 2e2d6605f51d
Version: 18.0 (1.1) MOZ
Firmware Version: v1.2device.cfg
Keywords: qawanted
Tim

Can we please help find a different component owner?

Moving to general doesn't help here
Flags: needinfo?(timdream)
Core::DOM since the code in question (see patch in bug 868914) was dom/base/nsScreen.cpp

We probably need to write tests here to prevent the regression again.

PS Read bug 868914 comment 26 for recent findings.
Component: General → DOM
Flags: needinfo?(timdream)
Product: Firefox OS → Core
Unable to provide a Regression Window. 

The following results were all produced using a Buri device. 

DOES occur in all 2.0 builds we have access to. 

DOES occur in all 1.4 we have access to.
20140422102131 (earliest 1.4) 
20140609091337 (latest 1.4)

DOES occur all of 1.3 builds we have access to. 
20140130145717 (earliest 1.3)

DOES NOT occur in all of 1.2 builds we have access to. 
20131031004003 (1.2 earliest)
20140213041204 (1.2 latest)

DOES NOT occur in all of 1.1 builds we have access to. 
20130915041201 (1.1 earliest)
20140213041204 (1.1 latest)
This is bad .... bug 868914 never worked?!?

Cervantes, you were the original author of mozLockOrientation right? Do you know who should we should talk to on this bug?
Flags: needinfo?(cyu)
I implemented the backend part of orientation lock to connect the sensors to DOM API. We need to find someone from the DOM team to take a look.
Flags: needinfo?(cyu)
Andrew - Can you find someone on your team to look into this?
Flags: needinfo?(overholt)
This is a gaia bug.
Assignee: nobody → ehsan
Component: DOM → Gaia::System::Lockscreen
Product: Core → Firefox OS
Flags: needinfo?(overholt)
We end up calling this setVisible function which does nothing <http://mxr.mozilla.org/gaia/source/apps/system/js/lockscreen_window.js#133> when we make the lock screen true, and we never call setVisible on the mozbrowser iframe that is running the game, so Gecko never knows that iframe is supposed to be hidden, and when the code running in the app tries to call mozLockOrientation, Gecko allows it because as far as it's concerned, the app is in the foreground.
Bug 985037 seems related.
Assignee: ehsan → nobody
I attached the debugging patches which print out a bunch of useful stuff which helped me figure out what' going on here.
Duplicate of this bug: 1008486
Duplicate of this bug: 1009682
Summary: [OPENC_1.3]the screen cannot be unlocked → Gaia doesn't put the running app in the background when the lockscreen shows up
Tim - Can you find someone to take a look?
Flags: needinfo?(timdream)
LOL, sorry about that. I can work on a quick patch while Greg is away.
Assignee: nobody → timdream
Status: NEW → ASSIGNED
Flags: needinfo?(timdream)
Actually, John, could you come up with the patch? Should be really quick.
Flags: needinfo?(jlu)
Yes I probably can land a one-liner patch quickly, but I'm not sure if it's gonna cause regression. On my list !
Flags: needinfo?(jlu)
I expect more than one-liner: this need a test case! :)
Assignee: timdream → jlu
After discussion with Tim, we think that my WIP patch above might not be the best approach to solving this issue -- the LockScreenWindow is after all a fake app, and the transitioning of foregroundness/backgroundness of other apps while locking/unlocking should be carried out by LockScreenWindowManager, in response to system's lock/unlock event broadcasts.

We will discuss with Alive and Greg further.
Please make sure the discussion happens on Monday so we could address this issue in a timely matter.

Please also figure out what we could do to prevent regression like this.
Flags: needinfo?(gweng)
Flags: needinfo?(alive)
I don't understand why the patch works. LockscreenWindow is NOT in v1.3 but this issues happens in v1.3
My guess: the game has some normal audio channel playing so we don't put it in background because of the well-known-bug 828283. NEED further investigation.
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #38)
> I don't understand why the patch works. LockscreenWindow is NOT in v1.3 but
> this issues happens in v1.3
> My guess: the game has some normal audio channel playing so we don't put it
> in background because of the well-known-bug 828283. NEED further
> investigation.

(Because bug 828283 was introduced before v1.3)
Can qa verify the regression window on v1.3 to verify the claim above?
We tried a window in comment 18, but failed to find anything useful.
John, did you find the cause of this bug?
Flags: needinfo?(jlu)
No I haven't dug into 1.3 code to see what's up there that's related to this issue.
Flags: needinfo?(jlu)
Yes, Alive is correct in the idea: the _normalAudioChannelActive is true in VisibilityManager in https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/system/js/visibility_manager.js#L45 when we lock the screen when the Skate Jumper app is currently running in foreground. Also, I also discovered that when Skate Jumper starts up, a visible-audio-channel-changed mozChromeEvent is fired with channel set to normal, in https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/system/js/visibility_manager.js#L71. It would not be set back to channel=none as long as the app is there running in the foreground (despite that there is apparently no music playing when the app launches into its main menu screen).

The similar behaviors can be observed with current master.

PS. Something interesting: when I was investigating this, I found out that our Marketplace app exhibits similar behavior: When it launches, a visible-audio-channel-changed mozChromeEvent is fired with channel set to normal. Now, if we lock the screen while the Marketplace app is running in the foreground, the _normalAudioChannelActive will be true in https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/visibility_manager.js#L83 and hidewindow event will not be publish()'ed.
The fix of this bug will regress 828283 again. Before we finish the work to migrate audio competing from gecko to gaia we have nothing to do with it unless we want to drop bug 828283.
De-nominating.
blocking-b2g: 1.3+ → 1.3?
(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #45)
> The fix of this bug will regress 828283 again. Before we finish the work to
> migrate audio competing from gecko to gaia we have nothing to do with it
> unless we want to drop bug 828283.
> De-nominating.

Can't kick out a cert blocker, sorry. This has to be fixed to ship a FxOS device.
blocking-b2g: 1.3? → 1.3+
(In reply to Jason Smith [:jsmith] from comment #46)
> (In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from
> comment #45)
> > The fix of this bug will regress 828283 again. Before we finish the work to
> > migrate audio competing from gecko to gaia we have nothing to do with it
> > unless we want to drop bug 828283.
> > De-nominating.
> 
> Can't kick out a cert blocker, sorry. This has to be fixed to ship a FxOS
> device.

Then this won't be a gaia bug.

BTW this is yet-another nice bug telling us we are making a wrong decision in that time. I hope we won't make another one this time due to timeframe issue.
Assignee: jlu → nobody
Component: Gaia::System::Lockscreen → General
Alive - Blocker bugs can't be kicked into the general component. We need another component to move this to that allows a dev team to take action on this. What component should this be moved to?
Flags: needinfo?(alive)
Flags: needinfo?(gweng)
(In reply to Jason Smith [:jsmith] from comment #48)
> Alive - Blocker bugs can't be kicked into the general component. We need
> another component to move this to that allows a dev team to take action on
> this. What component should this be moved to?

Put into audio channel since bug 828283 is an audio channel feature.
Component: General → AudioChannel
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #49)
> (In reply to Jason Smith [:jsmith] from comment #48)
> > Alive - Blocker bugs can't be kicked into the general component. We need
> > another component to move this to that allows a dev team to take action on
> > this. What component should this be moved to?
> 
> Put into audio channel since bug 828283 is an audio channel feature.

Summary
* Bug 828283 makes a playing-sound app always foreground even when screen is off to make it sounds.
* We need a gecko proper fix for bug 828283 and remove gaia hack in visibilityManager.

A rough idea: gaia could tell audio channel service who is the last active app to avoid to be stopped when it's background.
Per discussion with alive and timdream, indeed the patch of 828283 brings some problems in ffos, however, the design of skate jumper is also problematic. Since this issue only happens on certain App, I will co-work with partners to waive this one in 1.3 and target to fix in 2.1 release

Thanks
blocking-b2g: 1.3+ → ---
Side note: My patch at comment 35 does not properly fix the issue on master either, because it regresses bug 828283 by forcing foreground app into background (regardless of it playing music or not) during locking.
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #51)
> Per discussion with alive and timdream, indeed the patch of 828283 brings
> some problems in ffos, however, the design of skate jumper is also
> problematic. Since this issue only happens on certain App, I will co-work
> with partners to waive this one in 1.3 and target to fix in 2.1 release
> 
> Thanks

I don't think it's safe to necessarily blame the app entirely here. I think there might even be security implications of this since this allows a non-privileged app to prevent the phone being unlocked. Given the security risk, I think advising a partner to punt this is a very bad idea.

I want Paul to weigh on a sec rating here.
Group: b2g-core-security
blocking-b2g: --- → 1.3?
Flags: needinfo?(ptheriault)
(In reply to Jason Smith [:jsmith] from comment #53)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #51)
> > Per discussion with alive and timdream, indeed the patch of 828283 brings
> > some problems in ffos, however, the design of skate jumper is also
> > problematic. Since this issue only happens on certain App, I will co-work
> > with partners to waive this one in 1.3 and target to fix in 2.1 release
> > 
> > Thanks
> 
> I don't think it's safe to necessarily blame the app entirely here. I think
> there might even be security implications of this since this allows a
> non-privileged app to prevent the phone being unlocked. Given the security
> risk, I think advising a partner to punt this is a very bad idea.

When I say we can't push the blame entirely on the app - I mean other apps could easily trigger this workflow.
(In reply to Jason Smith [:jsmith] from comment #53)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #51)
> > Per discussion with alive and timdream, indeed the patch of 828283 brings
> > some problems in ffos, however, the design of skate jumper is also
> > problematic. Since this issue only happens on certain App, I will co-work
> > with partners to waive this one in 1.3 and target to fix in 2.1 release
> > 
> > Thanks
> 
> I don't think it's safe to necessarily blame the app entirely here. I think
> there might even be security implications of this since this allows a
> non-privileged app to prevent the phone being unlocked. Given the security
> risk, I think advising a partner to punt this is a very bad idea.
> 
> I want Paul to weigh on a sec rating here.

This bug was caused by the patch of 828283, which means the v1 train already has this bug, if we do have security concern, probably also need to think about the security update plan for all the FFOS 1.1 devices on the market.
So the screen gets locked, and then can't be unlocked. Apart from the temporary DoS (user can just restart the phone and never use that app again) this doesn't really sounds like much of a security issue. Very annoying UX, but sec-low at worst I think, and not blocking from a security perspective. 

The only thing I can think of is that if this behavior keeps happening, maybe users would disable the lockscreen. That would have an impact on the ecosystem. But that seems like a stretch, so marking this sec-low.

Note I also considered a foreground app being able to launch a web activity - but I think this case will be prevented since the lockscreen has a higher z-index that the activity chooser.
Flags: needinfo?(ptheriault)
Keywords: sec-low
Alright, I'll pull the blocking flag here then.
Group: b2g-core-security
blocking-b2g: 1.3? → ---
Status: ASSIGNED → NEW
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [cert] → [cert], [2.0-flame-test-run-3]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
QA Whiteboard: [QAnalyst-Triage+][lead-review+] → [QAnalyst-Triage?][lead-review+]
Flags: needinfo?(dharris)
Whiteboard: [cert], [2.0-flame-test-run-3] → [cert], [2.0-flame-test-run-3][2.1-flame-test-run-1]
QA Whiteboard: [QAnalyst-Triage?][lead-review+] → [QAnalyst-Triage+][lead-review+]
Flags: needinfo?(dharris)
Hi! Tim, John,

We had this issue since V1 train and 2.0, 2.0M and 2.1 are all affected.
Could you help to complete the patch and land it in 2.0M, 2.1 and master?
Thanks

--
Keven
blocking-b2g: --- → 2.0M?
Flags: needinfo?(timdream)
Flags: needinfo?(jlu)
Duplicate of this bug: 1067851
Will discuss tomorrow. (keeping needinfo)
Flags: needinfo?(jlu)
Update: This bug is about incorrectly set the app under lock screen as visible because of it's audio channel. As previous comments states, we can't do any workaround in Gaia along (the 'incorrect' behavior here itself is already an workaround implemented in bug 828283.

After talking to Alive, the proper fix can be 

A) Decouple audio channel w/ visibility state, implement a new browser API method, allowing Gaia System to explicitly control the audio channel.
B) Decouple audio channel w/ visibility state by implement bug 1034001.

If neither is possible in the release branch, we should (C) consider revert the behavior of bug 828283.

Thinker, KKuo, let's discuss this offline?

PS The patch attached in this bug is actually (C), which is not a fix w/o changing the behavior.
Flags: needinfo?(tlee)
Flags: needinfo?(timdream)
Flags: needinfo?(kkuo)
Summary: Gaia doesn't put the running app in the background when the lockscreen shows up → Gaia doesn't put the running app that occupies audiochannel in visibility background when the lockscreen shows up
It seems unreasonable to hook audio channel with visibility.  After the discussion with Tim offline, it seems the right time to revise audio channel API.  I think someone who working on media should be here.
Flags: needinfo?(tlee)
baku thinks this may be fixed by bug 876631.  Can someone test his patches from there to see if they do fix this?
See Also: → 1067205
(In reply to Andrew Overholt [:overholt] from comment #63)
> baku thinks this may be fixed by bug 876631.  Can someone test his patches
> from there to see if they do fix this?

:baku, could you elaborate what's being done in that bug? I don't see anything obvious regarding changing the behavior of audio channel management. Having nothing expose to Gaia System on explicit control makes me wonder too.

(I am also interested to know why a maybe-proper fix is put on halt for months, but that maybe is not a question for you)
Flags: needinfo?(amarchesini)
> :baku, could you elaborate what's being done in that bug? I don't see
> anything obvious regarding changing the behavior of audio channel
> management. Having nothing expose to Gaia System on explicit control makes
> me wonder too.


Actually, the bug that'll fix this issue is bug 853101 but that needs the refactoring of AudioChannelService first (bug 876631). Almost 1 year ago we (sicking, bent, mchen, me, and somebody else) had a meeting about a new version of the AudioChannel API.

This API introduces a method called 'treatNormalAsContent()' that will convert temporarily any 'normal' audio channel media element to 'content' for a particular app. This is what we need here:

when an app plays, before locking the screen, we have to call 'treatNormalAsContent() and magically, we don't need any hack for the visibility.

Unfortunately the refactoring was not the top priority for many of us and the patch I wrote has not been reviewed yet.
Flags: needinfo?(amarchesini)
Blocks: Woodduck
(In reply to Andrea Marchesini (:baku) from comment #65)
> Actually, the bug that'll fix this issue is bug 853101 but that needs the
> refactoring of AudioChannelService first (bug 876631). Almost 1 year ago we
> (sicking, bent, mchen, me, and somebody else) had a meeting about a new
> version of the AudioChannel API.
> 
> This API introduces a method called 'treatNormalAsContent()' that will
> convert temporarily any 'normal' audio channel media element to 'content'
> for a particular app. This is what we need here:
> 
> when an app plays, before locking the screen, we have to call
> 'treatNormalAsContent() and magically, we don't need any hack for the
> visibility.
> 
> Unfortunately the refactoring was not the top priority for many of us and
> the patch I wrote has not been reviewed yet.

Thank you for the pointer. I have set 2.2? accordingly and product management will work it out on priority.
feature-b2g: --- → 2.2?
Hi Andrea,

The bug is also reported by partner with 2.0M (bug 1067851). May I know when the target date for when will it been fix?

Thanks,
Josh
blocking-b2g: 2.0M? → 2.0M+
Depends on: 853101
Flags: needinfo?(amarchesini)
> The bug is also reported by partner with 2.0M (bug 1067851). May I know when
> the target date for when will it been fix?

From my side I think I need 3-4 days to update the existing patch and check that everything works as it should. Then there is the review process. I would like to have a feedback from overholt about the priority of this.
Flags: needinfo?(amarchesini) → needinfo?(overholt)
(In reply to Andrea Marchesini (:baku) from comment #68)
> > The bug is also reported by partner with 2.0M (bug 1067851). May I know when
> > the target date for when will it been fix?
> 
> From my side I think I need 3-4 days to update the existing patch and check
> that everything works as it should. Then there is the review process. I
> would like to have a feedback from overholt about the priority of this.

While we really need to focus on Service Worker, if this is a product blocker, I guess it'll have to take precedence :/
Flags: needinfo?(overholt)
On second thought, the refactoring required to properly fix this is way too risky for 2.0(anything) at this time.  We'll have to find a workaround and Andrea will work to land that refactoring early in the next cycle so it has time to bake.
(In reply to Andrew Overholt [:overholt] from comment #70)
> On second thought, the refactoring required to properly fix this is way too
> risky for 2.0(anything) at this time.  We'll have to find a workaround and
> Andrea will work to land that refactoring early in the next cycle so it has
> time to bake.

This is blocking a 2.2+ blocker in Camera as well. Although, I'm not entirely sure why Camera v2.0 and v2.1 are not affected, but v2.2 is. In the regression window identified for Bug 1071198, the regression is occurring in Gecko. See Bug 1071198 for more info.
I think having this fixed in the Gecko that FxOS 2.2 uses will not be a problem.
generic bug shouldn't be 2.0M+.
blocking-b2g: 2.0M+ → 2.0+
Judging by the efforts here I don't think we could deliver this for v2.0/v2.0M. Sorry.
blocking-b2g: 2.0+ → 2.0?
Do we have a workaround for 2.0?  Do we need one?

If not, let's make this a 2.2 blocker and I'll make sure it's on baku's plate and that of whoever reviews it in the short term.
blocking-b2g: 2.0? → 2.2+
Flags: needinfo?(timdream)
Flags: needinfo?(jocheng)
The workaround is option (C) in comment 61.
Flags: needinfo?(timdream)
Flags: needinfo?(kkuo)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #61)
> If neither is possible in the release branch, we should (C) consider revert
> the behavior of bug 828283.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #76)
> The workaround is option (C) in comment 61.

Since they requested it, I think reverting the behaviour of bug 828283 will be seen as a regression by at least one of our partners.  Is there no alternative?
Jonas, do you have an opinion here?  See comment 77.
Flags: needinfo?(jonas)
> A) Decouple audio channel w/ visibility state, implement a new browser API
> method, allowing Gaia System to explicitly control the audio channel.

So, this proposal is: instead implement the new AudioChannelAPI we discussed, let's implement a new API from scratch.
It seems a bit non-sense.

We already have a proposal for the new AudioChannel API that fixes this issue.
This proposal has code written and it has been already reviewed by mchen months ago.

Why we don't want to proceed with this?

Having the API you want to propose is not faster than finishing the new AudioChannel API.

> B) Decouple audio channel w/ visibility state by implement bug 1034001.

This seems similar to treadNormalAudioChannelAsContent() in the new AudioChannel API.
 
> If neither is possible in the release branch, we should (C) consider revert
> the behavior of bug 828283.

This would break the current behavior and I don't think it's what we want.
Let's ask sicking what he thinks about this issue.
I think ultimately it's a partner decision if they want to revert bug 828283 or not on their release branch. But it does mean breaking most 3rd party audio players as well as web based websites for playing audio. Including using YouTube as audio player.

We have discussed several possible ways to fix this problem. However they all require fairly large refactorings to the audio backend and so not something I would recommend taking on a branch that's as far down the release process as 2.0 (and even 2.1) is.
Flags: needinfo?(jonas)
(In reply to Andrea Marchesini (:baku) from comment #79)
> > A) Decouple audio channel w/ visibility state, implement a new browser API
> > method, allowing Gaia System to explicitly control the audio channel.
> 
> So, this proposal is: instead implement the new AudioChannelAPI we
> discussed, let's implement a new API from scratch.
> It seems a bit non-sense.
> 
> We already have a proposal for the new AudioChannel API that fixes this
> issue.
> This proposal has code written and it has been already reviewed by mchen
> months ago.
> 
> Why we don't want to proceed with this?
> 
> Having the API you want to propose is not faster than finishing the new
> AudioChannel API.
> 

I didn't realize your proposal when making the comment. We should be able to discard this proposal.

> > B) Decouple audio channel w/ visibility state by implement bug 1034001.
> 
> This seems similar to treadNormalAudioChannelAsContent() in the new
> AudioChannel API.
>  

Yes. I actually have no strong opinion as long as there is an API exist for us to fix this behavior.

> > If neither is possible in the release branch, we should (C) consider revert
> > the behavior of bug 828283.
> 
> This would break the current behavior and I don't think it's what we want.
> Let's ask sicking what he thinks about this issue.

Actually I am interested to know that kind of workaround 2.0M wants, or, alternatively, remove this from 2.0+. Kkuo could you comment please?
Flags: needinfo?(kkuo)
This is a bug fix request from partner since 1.3 and it keeps coming from different partners, different release.
I believe you will see the same request for next release, 2.1. 
But here I see is the fix plan is in 2.2 and not decided yet.
Form partner point of view, I don't care about plan A, B or C. But what I see is issue existing more than 4 months.

--
Keven
Flags: needinfo?(kkuo)
Flags: needinfo?(jocheng)
(In reply to Keven Kuo [:kkuo] from comment #82)
> This is a bug fix request from partner since 1.3 and it keeps coming from
> different partners, different release.
> I believe you will see the same request for next release, 2.1. 

Understood.  FWIW, I do not think this will be fixed until 2.2.
I ran into this issue today. I could not unlock the device after encountering the issue.

1. Slide to unlock to camera.
2. Take a picture with the camera.
3. View the preview of the picture in landscape mode.
4. Lock the device while in landscape mode.
5. Wake the phone back up.

Actual: The lockscreen will appear in landscape mode and will be completely messed up when viewed in portrait mode. The user will not be able to unlock the phone.
Whiteboard: [cert], [2.0-flame-test-run-3][2.1-flame-test-run-1] → [cert], permafail
Priority: -- → P1
(In reply to KTucker [:KTucker] from comment #84)
> I ran into this issue today. I could not unlock the device after
> encountering the issue.
> 
> 1. Slide to unlock to camera.
> 2. Take a picture with the camera.
> 3. View the preview of the picture in landscape mode.
> 4. Lock the device while in landscape mode.
> 5. Wake the phone back up.
> 
> Actual: The lockscreen will appear in landscape mode and will be completely
> messed up when viewed in portrait mode. The user will not be able to unlock
> the phone.

This is unrelated and I can't reproduce it on master. Could you file a separate bug if you could reproduce it?
Flags: needinfo?(ktucker)
Tim, I can no longer reproduce the issue as well. If i encounter it again, I will write up.
Flags: needinfo?(ktucker)
feature-b2g: 2.2? → ---
Consider to correct behavior when new audiochannel completed.
blocking-b2g: 2.2+ → ---
tracking-b2g: --- → +
[Update]

Verified the bug and then I cannot reproduce the issue with master and v2.2. I mark the ticket to resolve but sill keep monitor this.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.