User is interacting with the gallery app in landscape orientation. User examines a picture and chooses to share it in a MMS message. After returning to gallery, gallery is locked in portrait view and user cannot switch to landscape view. Repro Steps: 1) Update a Flame to BuildID: 20140611091244 2) Launch Gallery 3) Hold device in landscape orientation 4) Share a picture via Messaging 5) Send message Actual: User is returned to gallery, gallery orientation is locked in portrait mode Expected: User is returned to gallery, gallery adapts to display in correct orientation v2.0 Environmental Variables: Device: Flame v2.0 MOZ BuildID: 20140611091244 Gaia: a0f9f1f41a436daad8a249ce85df80a81a5ba2d5 Gecko: 0c0effd600c4 Version: 32.0a2 Firmware Version: v10G-2 Notes: Repro frequency: 100% See attached: screenshot

Please make sure QAnalyst-triage is being flagged & Joshua is being flagged for review.

QA-Wanted to check the branches

This issue does not repro on the Flame v1.4 MOZ ril. (The user is not returned to the gallery app after sending the message, and there is no 'x' to go back manually.) This issue DOES repro on the Buri v2.0 MOZ ril. Environmental Variables: Device: Flame 1.4 Build ID: 20140612000202 Gaia: 7fc73d4cb1bece31f50e8ccf6fb98af3984a9ebf Gecko: bcd308fbbf38 Version: 30.0 (1.4) Firmware Version: v10G-2 v2.0 Environmental Variables: Device: Buri v2.0 MOZ BuildID: 20140612040203 Gaia: 41db6954a67efc55016744bc8f6591ae9e07a285 Gecko: 9e8e3e903484 Version: 33.0a1 Firmware Version: v1.2-device.cfg Leaving qawanted to finish checking the Open_C v2.0.

This issue DOES occur on Open C 2.0 Open_C 2.0 Environmental Variables: Device: Open_C 2.0 Build ID: 20140612000201 Gaia: 2bb66630315299ca947e40fcec23c9f7ea012111 Gecko: 670d69879f0e Version: 32.0a2 (2.0) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 When returning to the Gallery app the screen is locked in portrait orientations, even while the user is holding the phone in a landscape orientation This issue does NOT occur on Buri or Open C 1.4 Buri 1.4 Environmental Variables: Device: Buri 1.4 Build ID: 20140612063006 Gaia: 80bf1039c6ce8bcde57ce06ecb09e40c18c538c6 Gecko: 39b6237907d9 Version: 30.0 (1.4) MOZ Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 Open_C 1.4 Environmental Variables: Device: Open_C 1.4 Build ID: 20140612000202 Gaia: 7fc73d4cb1bece31f50e8ccf6fb98af3984a9ebf Gecko: bcd308fbbf38 Version: 30.0 (1.4) Firmware Version: P821A10V1.0.0B06_LOG_DL User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 When returning to the Gallery app the screen shows properly in landscape mode while the user is holding the phone in a landscape orientation

B2G Inbound Regression Window: Last Working: Environmental Variables: Device: Flame Master Build ID: 20140424053001 Gaia: 4b6c9d4929c57005ab142e8eb3dc6783d55c427c Gecko: c30df002e626 Version: 31.0a1 (Master) Firmware Version: v121-2 First Broken: Environmental Variables: Device: Flame Master Build ID: 20140424083005 Gaia: afa7142f2dc49b5b131ca48bfe818e2dfda15298 Gecko: ba6ea9f01a97 Version: 31.0a1 (Master) Firmware Version: v121-2 Last Working Gaia First Broken Gecko: Issue does NOT reproduce Gaia: 4b6c9d4929c57005ab142e8eb3dc6783d55c427c Gecko: ba6ea9f01a97 First Broken Gaia Last Working Gecko: Issue DOES reproduce Gaia: afa7142f2dc49b5b131ca48bfe818e2dfda15298 Gecko: c30df002e626 Gaia pushlog: https://github.com/mozilla-b2g/gaia/compare/4b6c9d4929c57005ab142e8eb3dc6783d55c427c...afa7142f2dc49b5b131ca48bfe818e2dfda15298 Possible cause: Bug 936729

Josh - I think you forgot to check 1.3 here.

(In reply to Jason Smith [:jsmith] from comment #6) > Josh - I think you forgot to check 1.3 here. Oh wait - disregard, I see this mentions this doesn't reproduce on 1.4.

Oleg - Can you take a look?

(In reply to Jason Smith [:jsmith] from comment #8) > Oleg - Can you take a look? Sure, will look into it.

Bug 936729 changed the activity from "window" to "inline", that's the only meaningful change for this bug. Therefore I suspect this is more a window manager issue. Alive, can you please havea look?

Yap, the activity caller is not locking the orientation again.

The problem seems: activityclosing is not fired "to" the caller app and hence the handler to set orientation is not triggered. I am still checking why.

The reason is simple: the activityclosing event is dispatched at window and the caller appWindow is listening on its own element. Proposed fix: dispatch the event both on window and the activityWindow's embedder.

Proposed fix: listening to the inner event of the embedded app window instances. Will update unit test if necessary.

Comment on attachment 8441993 [details] https://github.com/mozilla-b2g/gaia/pull/20672 I think I broke something like appopen event is not catched by other modules..

Comment on attachment 8441993 [details] https://github.com/mozilla-b2g/gaia/pull/20672 v2: Decouple publish and broadcast Let's see what etienne think.

Comment on attachment 8441993 [details] https://github.com/mozilla-b2g/gaia/pull/20672 Wow I'm pretty uncomfortable with the broadcast method calling handle_* :/ For the activity* and popup* events we're listening on this.element but they are dispatched on the window :/ How about modifying the publish method to end with something like that: ``` if (this.rearWindow && this.element) { this.element.dispatchEvent(evt); } else { window.dispatchEvent(evt); } ``` This way for all nested windows, we dispatch the published events on the element first, let them bubble to their rearWindow and eventually to the window. Looks like it's working pretty well for this bug, not sure if I'm missing anything.

As discussed on IRC, attaching my POC to make sure we're talking about the same thing.

Ya that works. Don't really know why it failed on my device yesterday :/

Comment on attachment 8442671 [details] https://github.com/mozilla-b2g/gaia/pull/20731 \o/

Looks like I break the add-bookmark-to-homescreen activity. Looking..

(In reply to Alive Kuo [:alive][NEEDINFO!][OOO from 6/23 until 6/30] from comment #21) > Looks like I break the add-bookmark-to-homescreen activity. Looking.. The reason is we are setVisible(false) to browser app when activity is opened, and it setVisible to its frontWindow which is the bookmark activity to false. That is an old hack to fix bug 914412, but it was already gone by some unknown reason. And since this function is never successfully reached and we don't see bug like 914412 again, we should remove it.

master https://github.com/mozilla-b2g/gaia/commit/3a3f6dcf99970348dd486d072f24a7d1df0df698

v2.0: https://github.com/mozilla-b2g/gaia/commit/d5f625440ffe542103a302fd2a75fe2a7f28b3ff

This issue has been verified successfully on Flame 2.0 & 2.1. See attachment: Verify_Video_Flame.MP4 Reproducing rate: 0/10 Flame v2.0 version: Gaia-Rev 8d1e868864c8a8f1e037685f0656d1da70d08c06 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3 Build-ID 20141127000203 Version 32.0 Flame v2.1 version: Gaia-Rev 5372b675e018b6aac97d95ff5db8d4bd16addb9b Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/f34377ae402b Build-ID 20141127001201 Version 34.0