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

VERIFIED FIXED in Firefox OS v2.0

Status

Firefox OS
Gaia::System::Window Mgmt
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: Ross Kuhlman (rkuhlman@qanalydocs.com), Assigned: alive)

Tracking

({regression})

unspecified
2.0 S4 (20june)
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

Details

(Whiteboard: [p=2])

Attachments

(4 attachments, 1 obsolete attachment)

Created attachment 8438776 [details]
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
Please make sure QAnalyst-triage is being flagged & Joshua is being flagged for review.
Flags: needinfo?(rkuhlman)
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst Triage?]
Flags: needinfo?(rkuhlman) → needinfo?(jmitchell)
QA-Wanted to check the branches
Flags: needinfo?(jmitchell)
Keywords: qawanted
(Reporter)

Updated

4 years ago
QA Whiteboard: [QAnalyst Triage?] → [QAnalyst-Triage?]
QA Contact: 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.
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
Flags: needinfo?(jmitchell)
Keywords: qawanted → regression
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
QA Contact: rpribble → jmitchell
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
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Keywords: regressionwindow-wanted
Josh - I think you forgot to check 1.3 here.
Flags: needinfo?(jmitchell)
Keywords: qawanted
(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.
Flags: needinfo?(jmitchell)
Keywords: qawanted
Oleg - Can you take a look?
Blocks: 936279
Flags: needinfo?(azasypkin)
(In reply to Jason Smith [:jsmith] from comment #8)
> Oleg - Can you take a look?

Sure, will look into it.

Updated

4 years ago
Blocks: 936729
No longer blocks: 936279
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?
Component: Gaia::Gallery → Gaia::System::Window Mgmt
Flags: needinfo?(azasypkin) → needinfo?(alive)

Updated

4 years ago
blocking-b2g: --- → 2.0?

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Yap, the activity caller is not locking the orientation again.
Assignee: nobody → alive
Flags: needinfo?(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.
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.
Whiteboard: [p=2]
Created attachment 8441993 [details] [review]
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.
Attachment #8441993 - Flags: feedback?(etienne)
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..
Attachment #8441993 - Flags: feedback?(etienne)
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.
Attachment #8441993 - Flags: feedback?(etienne)

Updated

4 years ago
blocking-b2g: 2.0? → 2.0+
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.
Attachment #8441993 - Flags: feedback?(etienne) → feedback-
Created attachment 8442212 [details] [diff] [review]
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.
Attachment #8442212 - Flags: feedback?(alive)
Created attachment 8442671 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/20731

Ya that works. Don't really know why it failed on my device yesterday :/
Attachment #8441993 - Attachment is obsolete: true
Attachment #8442671 - Flags: review?(etienne)
Attachment #8442212 - Flags: feedback?(alive) → feedback+
Target Milestone: --- → 2.0 S4 (20june)
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
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed
Resolution: --- → FIXED
Created attachment 8530017 [details]
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.