963707 - [B2G][Twitter][Camera]Camera does not display properly in landscape orientation when attaching pic to tweet.

Status: RESOLVED FIXED

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

Description

[Ross Kuhlman ([e-mail])]

Attachment: TwitterCameraLandscape.txt

The user is posting a tweet and chooses to attach an image taken from the camera. While holding the phone in landscape orientation, the camera does not display onscreen properly. The buttons do not span the entire bottom of the screen, and the camera view is rotated 90%, so that panning the camera up/down causes the screen to pan left/right.

Repro Steps:
1) Updated Buri to BuildID: 20140122004001
2) Launch Twitter. (This issue occurs in the marketplace app AND the E.Me version of twitter)
3) Tap the 'Compose Tweet' button in the top right corner of the screen.
4) Tap the camera button in the lower left.
5) Choose to attach a picture from the camera.
6) While camera is active, hold device in landscape orientation.

Actual:
The Cancel and Camera buttons do not span the entire width of the screen. The camera image is rotated sideways such that vertical panning of the device is displayed as horizontal panning on the screen.

Expected:
Buttons are properly aligned/positioned. Camera is displayed with proper alignment.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20140121004137
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Gecko: 6f7dfe36ab6c
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
See attached: logcat, screenshot

Comment 1

[Ross Kuhlman ([e-mail])]

Attachment: CameraRotated.png

Environmental Variables:
Device: Buri 1.2 MOZ
BuildID: 20131021004006
Gaia: 1fd315337d8ae891c3024e4c682c4c50797ea40e
Gecko: d585fe28cd55
Version: 26.0a2
Firmware Version: V1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

Can we find out if this reproduces on 1.2 or 1.1?

Comment 3

[J Zimbrick]

This does not reproduce in 1.1 or 1.2, the camera behaves like it is still in portrait mode after rotating to what should be landscape mode. The camera icon itself rotates, but no other UI changes.

1.1 Environmental Vairables:
Device: Buri v1.1 Mozilla RIL
BuildID: 20140124041702
Gaia: c434fe9a0e823029796805e141cfa983cda2d246
Gecko: 1f6e89d119a9
Version: 18.0
Base Image: V1.2-device.cfg

1.2 Environmental Variables:
Device: Buri v1.2 Mozilla RIL
BuildID: 20140124004003
Gaia: 539a25e1887b902b8b25038c547048e691bd97f6
Gecko: da5fcd064407
Version: 26.0
Base Image: V1.2-device.cfg

Comment 4

[Jason Smith [:jsmith]]

Can I get a video of this bug? I'm trying to understand if this impacts the viewfinder or not.

Comment 5

[J Zimbrick]

After doing some searching, this actually appears to be a dupe of Bug 948226, though 948226 was written for Twitter through the browser, they both list essentially the same steps and produce the same result.

I haven't actually been able to repro this issue exactly as shown in the CameraRotated.png attachment, but the steps provided on both bugs always produce the same results as Bug 948226 for me.

948226 is resolved fixed, but doesn't appear to have been uplifted yet.

Resolving as a dupe and clearing the tags.

Comment 6

[Jason Smith [:jsmith]]

No - not a dupe. That bug landed on 1/14/2014, where as this bug was filed on 1/21/2014. The patch from that bug is already included here during testing.

Comment 7

[J Zimbrick]

If that fix landed, it certainly did not work, or something rebroke the twitter camera in exactly the same way.

Following the steps for bug 948226 and for this one (963707) produce the exact same break.

Comment 8

[J Zimbrick]

To clarify, both bug 948226 and bug 963707 still reproduce on the latest 1.3 Buri build, and both reproduced before the 14th, on the 14th, and after the 14th. 

The landed fix from bug 948226 didn't appear to change anything on 1.3.

Bug 948226 includes the same steps as bug 963707, but through the browser, rather than the app. The app just appears to mirror the site, and following the steps listed in Comment 0 of this bug produces the same break in the app as 948226 does in the browser.

And I'm willing to bet that both bug 948226 and bug 963707 have the same regression window, which leads me to believe that this is indeed a dupe. I'll verify that when I get in on Monday.

Comment 9

[Jason Smith [:jsmith]]

(In reply to J Zimbrick from comment #8)
> To clarify, both bug 948226 and bug 963707 still reproduce on the latest 1.3
> Buri build, and both reproduced before the 14th, on the 14th, and after the
> 14th. 
> 
> The landed fix from bug 948226 didn't appear to change anything on 1.3.
> 
> Bug 948226 includes the same steps as bug 963707, but through the browser,
> rather than the app. The app just appears to mirror the site, and following
> the steps listed in Comment 0 of this bug produces the same break in the app
> as 948226 does in the browser.
> 
> And I'm willing to bet that both bug 948226 and bug 963707 have the same
> regression window, which leads me to believe that this is indeed a dupe.
> I'll verify that when I get in on Monday.

It doesn't matter if that bug failed to fix the issue at this point - this bug acts as a followup to that bug. Followups do not result in reopening bugs - they result opening up a followup bug to the issue. I still need a video showcasing the bug to move forward here.

Comment 10

[J Zimbrick]

https://www.youtube.com/watch?v=hypZvuXHJBE

The issue can be seen at 0:29, putting the phone in to landscape mode breaks the look of the camera. This seems to happen 100% of the time when using the camera through Twitter (either the browser, app, or e.me versions).

Comment 11

[Jason Smith [:jsmith]]

Okay - the video definitely showcases that the viewfinder's orientation is incorrect when in landscape, so this is a pretty serious regression.

Comment 12

[J Zimbrick]

Regression Window:

Last Working Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131031040201
Gaia: 412fd463bcb81f0e8bebf6d32500d0c02712748d
Gecko: f0d363d72753
Version: 28.0a1
Base Image: V1.2-device.cfg

First Broken Environmental Variables:
Device: Buri v1.3 Mozilla RIL
BuildID: 20131101040203
Gaia: ccdf357ea150fc7d8b8a4b74c7adf31e7a57e465
Gecko: abe6790a5dd8
Version: 28.0a1
Base Image: V1.2-device.cfg

Comment 13

[Salem Elkabule]

I'm experiencing this issue in Facebook as well, Would you like me to open a new bug or this would be the same bug?

Comment 14

[Jason Smith [:jsmith]]

(In reply to Salem Elkabule from comment #13)
> I'm experiencing this issue in Facebook as well, Would you like me to open a
> new bug or this would be the same bug?

Probably the same bug.

Comment 15

[Hema Koka [:hema]]

mikeh: could you please take this one and see whats going on

Comment 16

[Mike Habicher [:mikeh] (high bugzilla latency)]

This is a window management problem when using orientation-locked apps to service activities.

Comment 17

[Hema Koka [:hema]]

Gregor,

Alive and Tim are probably out for new years. Is there anyone from the systems frontend team who can help look into this issue. There are similar bugs that alive fixed (https://bugzilla.mozilla.org/show_bug.cgi?id=948226 and https://bugzilla.mozilla.org/show_bug.cgi?id=874737)

Comment 18

[Dale Harvey (:daleharvey)]

I can take a look at this, unless anyone wants to steal it from me

Comment 19

[Dale Harvey (:daleharvey)]

doesnt reproduce on master, building 1.3 now

Comment 20

[Dale Harvey (:daleharvey)]

Actually my keon doesnt do orientation, handy, filed https://bugzilla.mozilla.org/show_bug.cgi?id=965585 and trying on peak now

Comment 21

[Dale Harvey (:daleharvey)]

reproduced on 1.3 peak, but not nightly

Comment 22

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

Dale let me know if you need my help to review.

(In reply to Dale Harvey (:daleharvey) from comment #21)
> reproduced on 1.3 peak, but not nightly

Do you mean not reproducible on master?

Comment 23

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

Not reproducible on master with ev.me twitter or twitter app. Something wrong with v1.3 uplift?

Comment 24

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

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

Shame on me :/

The root cause is the transition control is totally different for v1.4 and v1.3
In v1.4 all windows are inherited from appWindow and has a appTransitionController as submodule to control the transitions. Since the orientation is locked after the open transition is done in AppTransitionController, we don't need to worry about window type. But in v1.3 appWindow is not finetune so activitiyWindow has its own transition control, and don't know why I forgot to lock orientation after the activity window is opened.

Comment 25

[Etienne Segonzac (:etienne)]

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

All good!

Tested it one last time just to be sure :)

Comment 26

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

Achievement: Land v1.3+ on lunar new year's eve!
https://github.com/mozilla-b2g/gaia/commit/14ce5cb2f1becd436976315eede1f63760000b9d

Comment 27

[Dale Harvey (:daleharvey)]

Hah good work, mostly got myself familiar yesterday and was starting to get to the issue, but good to have it fixed, have a good holiday

Comment 28

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

(In reply to Dale Harvey (:daleharvey) from comment #27)
> Hah good work, mostly got myself familiar yesterday and was starting to get
> to the issue, but good to have it fixed, have a good holiday

Thanks for your effort! See ya in Paris!