1024168 - [B2G][Gallery]Sharing file from gallery to messaging locks gallery in portrait mode

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Ross Kuhlman ([e-mail])]

Attachment: GalleryRotationLog.txt

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

Comment 1

[Jason Smith [:jsmith]]

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

Comment 2

[Joshua Mitchell (Inactive)]

QA-Wanted to check the branches

Comment 3

[Rachel Pribble [:rpribble]]

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.

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

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

Comment 5

[Joshua Mitchell (Inactive)]

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

Comment 6

[Jason Smith [:jsmith]]

Josh - I think you forgot to check 1.3 here.

Comment 7

[Jason Smith [:jsmith]]

(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.

Comment 8

[Jason Smith [:jsmith]]

Oleg - Can you take a look?

Comment 9

[Oleg Zasypkin [:azasypkin]]

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

Sure, will look into it.

Comment 10

[Julien Wajsberg [:julienw]]

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?

Comment 11

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

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

Comment 12

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

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.

Comment 13

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

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.

Comment 14

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

Attachment: https://github.com/mozilla-b2g/gaia/pull/20672

Proposed fix: listening to the inner event of the embedded app window instances.

Will update unit test if necessary.

Comment 15

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

Comment on attachment 8441993 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20672

I think I broke something like appopen event is not catched by other modules..

Comment 16

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

Comment on attachment 8441993 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20672

v2: Decouple publish and broadcast
Let's see what etienne think.

Comment 17

[Etienne Segonzac (:etienne)]

Comment on attachment 8441993 [details] [review]
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.

Comment 18

[Etienne Segonzac (:etienne)]

Attachment: POC - publish from the element when we have a rearWindow

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

Comment 19

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

Attachment: https://github.com/mozilla-b2g/gaia/pull/20731

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

Comment 20

[Etienne Segonzac (:etienne)]

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

\o/

Comment 21

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

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

Comment 22

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

(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.

Comment 23

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

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

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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

Comment 25

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

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