1. Title : [System] [Video] Homescreen changes orientation on Video app exit. 2. Precondition : Run Video app and change orientation to landscape. 3. Tester's Action : Stay landscape and long-press Home to show card view. Then drap up to exit the video app. 4. Detailed Symptom (ENG.) : Homescreen is now in landscape. 5. Expected : Homescreen is always portrait. 6.Reproducibility: Y 1)Frequency Rate : 100% 7.Gaia Master/v1-train : Reproduced 8.Gaia Revision: 43debc4f11d06440dd15f5279ffe596cdde46a84 9.Personal email id: hanj.kim25@gmail.com Similar issue is found when Share->Bluetooth is selected on a video. The bluetooth confirmation dialog is in landscape and it hides the string message in half. (Seems that this dialog should stay in portrait.)

Related bugs found: 868914 and 843390 The bug 868914 has a patch. However when its patch was tested, the problem on video app exit still exists.

Setting needinfo flag to Alive, to draw attention.

The commit you provide is a very very old change in master. And with current master I couldn't repro it. BTW, bug 868914 isn't for this case anyway. It's to prevent an app is inappropriately using the orientation API. commit 43debc4f11d06440dd15f5279ffe596cdde46a84 Merge: 1087df8 4f84d8b Author: David Scravaglieri <dscravaglieri@mozilla.com> Date: Wed Nov 28 04:24:07 2012 -0800 Merge pull request #6679 from dscravag/nightly2 Nightly 2012-11-28

(In reply to Alive Kuo [:alive] from comment #3) > The commit you provide is a very very old change in master. > And with current master I couldn't repro it. > > BTW, bug 868914 isn't for this case anyway. It's to prevent an app is > inappropriately using the orientation API. > > commit 43debc4f11d06440dd15f5279ffe596cdde46a84 > Merge: 1087df8 4f84d8b > Author: David Scravaglieri <dscravaglieri@mozilla.com> > Date: Wed Nov 28 04:24:07 2012 -0800 > > Merge pull request #6679 from dscravag/nightly2 > > Nightly 2012-11-28 Sorry I am not familiar with using code aurora. I guess I picked up a wrong number. Here are other info. AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.075 Mozilla build ID: 20130425070204 Please re-confirm.. thanks!

(In reply to Leo from comment #0) > Similar issue is found when Share->Bluetooth is selected on a video. The > bluetooth confirmation dialog is in landscape and it hides the string > message in half. (Seems that this dialog should stay in portrait.) BTW this is a different issue, we don't lock orientation for BT transfer I think. It's worthy to open another bug to trace this.

(In reply to Leo from comment #4) > (In reply to Alive Kuo [:alive] from comment #3) > > Sorry I am not familiar with using code aurora. I guess I picked up a wrong > number. > > Here are other info. > > AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.075 > Mozilla build ID: 20130425070204 > > Please re-confirm.. thanks! I still couldn't reproduce using 20130425070204 build. Is it a device-specific issue? My view: 1. Open video app 2. Long press homebutton->cardsview shows->Now it's portrait-primary mode already. 3. After moving out video app in card view, homescreen is portrait-primary too.

(In reply to Alive Kuo [:alive] from comment #5) > > BTW this is a different issue, we don't lock orientation for BT transfer I > think. It's worthy to open another bug to trace this. Okay, I have opened another bug for it, Bug 869346.

(In reply to Alive Kuo [:alive] from comment #6) > I still couldn't reproduce using 20130425070204 build. Is it a > device-specific issue? > > My view: > 1. Open video app > 2. Long press homebutton->cardsview shows->Now it's portrait-primary mode > already. > 3. After moving out video app in card view, homescreen is portrait-primary > too. Now after 3, would you try rotating the device and see if homescreen rotates as well? It does rotate on my device..

Hi Jason, Is this a Video app specific issue? Would you pin-point what the issue is, if you know? Thanks

Probably likely a Gaia::System issue. Alive is definitely the person who would be good to talk to here about this. I'd recommend trying to reproduce this on a recent build to double check the bug reproduces on a recent build.

Could you please provide gaia commit info? This looks like Bug 834642 - Lock screen orientation to portrait-primary in cards view.

(In reply to Alive Kuo [:alive] from comment #11) > Could you please provide gaia commit info? This looks like Bug 834642 - Lock > screen orientation to portrait-primary in cards view. The gaia revision is 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c and AU is AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.071 (Sorry I kept on giving you wrong version numbers. The way I retrieve the info was messed up. Now I know the correct way.) The code I have currently has the changes in Bug 834642 patch. One thing I found now is, if I comment out 'windows.removeChild' in removeFrame function of windows_manager.js, then the homescreen stays portrait. function removeFrame(origin) { var app = runningApps[origin]; var frame = app.frame; if (frame) { //windows.removeChild(frame); clearFrameBackground(frame); } Anything wrong happening in windows.removeChild ?

(In reply to Leo from comment #12) > (In reply to Alive Kuo [:alive] from comment #11) > > Could you please provide gaia commit info? This looks like Bug 834642 - Lock > > screen orientation to portrait-primary in cards view. > > The gaia revision is 5cbb19e4bb78a7ad879fbe4b9a841e1c35714f5c and AU is Nice. Thanks! > One thing I found now is, if I comment out 'windows.removeChild' in > removeFrame function of windows_manager.js, then the homescreen stays > portrait. > > function removeFrame(origin) { > var app = runningApps[origin]; > var frame = app.frame; > > if (frame) { > //windows.removeChild(frame); > clearFrameBackground(frame); > } > > Anything wrong happening in windows.removeChild ? Need more investigation. Checking.

More info. I have been informed that any application using "screen" object is creating this issue and we suspect that destructor of nsScreen.cpp has some problems.

Taken first but currently I have lots of bugs handy so I will back to this soon, this week or next.

It's strange that why removeFrame is invoked. We only remove a frame when it's killed.

(In reply to Alive Kuo [:alive] from comment #16) > It's strange that why removeFrame is invoked. We only remove a frame when > it's killed. Hi Alive, It is killed, by 'drap up to exit the video app.'.

When we kill an app in card view, the current sequence is as follows. (1) kill(app's origin) in window_manager.js (2) removeFrame() (3) windows.removeChild(frame) (4) Finalize() of app's nsFrameLoader (5) nsScreen->Reset() and nsScreen::~nsScreen() => this Reset() function sets orientation to auto. (6) orientation related code does not exist anymore. ==> That is, homescreen's orientation became auto. nsScreen::Reset() is called from nsGlobalWindow::FreeInnerObjects() and nsScreen::~nsScreen(). Those cases happen when app's frame is destroyed. (when nsFrameLoader::Finalize() is called) In my opinion, Root cause is nsScreen::Reset() calls hal::UnlockScreenOrientation(). I think we should remove hal::UnlockScreenOrientation() from nsScreen::Reset(). In those issue cases, calling nsScreen::Reset() is necessary but hal::UnlockScreenOrientation() is not. Because window_manager.js is responsible for managing app's orientation, reset orientation in nsScreen is not needed. on the contrary, I think it makes side-effect only.

Hi, please see https://bugzilla.mozilla.org/show_bug.cgi?id=851642#c27, https://bugzilla.mozilla.org/show_bug.cgi?id=851642#c30 We have the same conclusion there ;)