979086 - [Sora][Message][MMS]The picture should display in the middle of the screen in Landscape mode.

Status: RESOLVED DUPLICATE of bug 960215

(Firefox OS Graveyard :: Gaia::Gallery, defect, P1)

Description

[sync-1]

Firefox OS v1.3
 Mozilla build ID: 20140208004002
 
 Created an attachment (id=649958)
 picture
 
 DEFECT DESCRIPTION:
 ->The picture isn't in the middle of the screen.
 
  REPRODUCING PROCEDURES:
 ->Enter"Messages"to create a MMS;
 ->Add a picture,tap the picture select"view",then select landscape mode;
 ->You can find the picture isn't in the middle of the screen.(ko)
 
 Note:Beetle lite FF isn't exist this behavior.
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:100%

Comment 1

[sync-1]

Attachment: picture

Comment 2

[sync-1]

Attachment: picture

Comment 3

[Jason Smith [:jsmith]]

Can someone on Moz confirm this on the latest 1.3?

Comment 4

[Josh Schmitt [Joshs]]

Issue repro's on the latest 1.3 build.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140310004001
Gaia: 78c30d7ed6f6e30337d6c05453b867f5e97e42bc
Gecko: 00f249d54bda
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 5

[Jason Smith [:jsmith]]

Does this reproduce on the 1.1 Buri?

Comment 6

[sync-1]

(In reply to comment #3)
 > Comment from Mozilla:Does this reproduce on the 1.1 Buri?
 > 
 
 No landscape mode options on v1.1

Comment 7

[Jason Smith [:jsmith]]

I don't see a landscape mode option here. What are you selecting here?

QA Wanted to clarify this as well.

Comment 8

[sync-1]

(In reply to comment #5)
 > Comment from Mozilla:I don't see a landscape mode option here. What are you
 > selecting here?
 > 
 > QA Wanted to clarify this as well.
 > 
 
 Settings->Display->Lock orientation

Comment 9

[Cody Roesch [:croesch]]

I was able to repro MMS images not being centered when viewing the image in the latest 1.3 buri build.

1. Launch SMS/MMS app with phone in Portrait orientation.
2. Tap on add attachment icon.
3. Choose an image and tap done which adds the image to the MMS.
4. Rotate the phone to landscape orientation and tap on the attached image.
5. Tap View and notice the image appears in the center of the screen.
6. Rotate phone back to portrait view and notice the image is now probably in the top left corner of the screen.

(Note if the image is cropped when choosing the image in step 3, the location of the image in step 6 can vary. For instance if the image is cropped to the lowest possible size, the image appears in the bottom right corner in step 6.)

In Buri V1.1 latest, there is no way to get this as stated above.
In Buri V1.4 latest, there is no rotation of images in the MMS even with orientation lock off. No way to repro this bug in v1.4.

Environmental Variables
Device: Buri v1.3 Moz Ril
Build ID: 20140312004001
Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/c629684b0eae
Gaia: df157ce3a3f841850a1cce8f057f8e7f547fb9f8
Platform Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 10

[Cody Roesch [:croesch]]

Wanted to add that I saw this bug title referenced not centered in landscape mode and above I described how it's not lined up in portrait. To get the issue in landscape orientation, just start in landscape orientation in step 3 and then in step 6, change to portrait then back to landscape. Image will not be centered in landscape.

Comment 11

[Jason Smith [:jsmith]]

Ah okay - that explains why I didn't see the bug - I tested this on 1.4 & was unable to reproduce. Sounds like this is a 1.3-specific problem.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Ah okay - that explains why I didn't see the bug - I tested this on 1.4 &
> was unable to reproduce. Sounds like this is a 1.3-specific problem.

Actually reading the above comments again - this doesn't make sense. The comments are implying that you aren't reproducing this on 1.3, but you are indicating you are able to reproduce.

Please re-address the qawanted request again with the right details.

Comment 13

[Sarah Parsons]

This issue does reproduce on the latest 1.3 Build ID: 20140312004001

Environmental Variables
Device: Buri v1.3 Moz Ril
Build ID: 20140312004001
Gecko: https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/c629684b0eae
Gaia: df157ce3a3f841850a1cce8f057f8e7f547fb9f8
Platform Version: 28.0
Firmware Version: v1.2-device.cfg

(In reply to Jason Smith [:jsmith] from comment #12)
> (In reply to Jason Smith [:jsmith] from comment #11)
> > Ah okay - that explains why I didn't see the bug - I tested this on 1.4 &
> > was unable to reproduce. Sounds like this is a 1.3-specific problem.
> 
> Actually reading the above comments again - this doesn't make sense. The
> comments are implying that you aren't reproducing this on 1.3, but you are
> indicating you are able to reproduce.
> 
> Please re-address the qawanted request again with the right details.

Comment 14

[Jason Smith [:jsmith]]

When the picture is rendered on the left side of the screen, is any of the picture getting cut off here? Trying to understand if the only impact here is the fact the picture isn't centered or if there's more issues than that here.

Comment 15

[Cody Roesch [:croesch]]

Yes at step 6 in comment 9, the image will be cut off partially. This is true for both methods described for landscape and portrait methods mentioned in comment 10.

Adding screenshots for reference. (Before Flipping and After Flipping)

Comment 16

[Cody Roesch [:croesch]]

Attachment: Before Flipping.png

Comment 17

[Cody Roesch [:croesch]]

Attachment: After Flipping.png

Comment 18

[Jason Smith [:jsmith]]

That's probably bad then if the image is getting cut off then.

Comment 19

[J Zimbrick]

Nightly Regression Window:

Last Working Environmental Variables:
Device: Buri
BuildID: 20140130004001
Gaia: 8defa5bf0cbce290c649e564b7f3ebe708e19b23
Gecko: 6b12800e0e46
Version: 28.0a2
Base Image: V1.2-device.cfg

First Broken Environmental Variables:
Device: Buri
BuildID: 20140130164001
Gaia: 9fb8dff0277eb9ffe88f6efeb4426ec21c01395b
Gecko: 27ea1a450ed7
Version: 28.0a2
Base Image: V1.2-device.cfg

Last Working Gaia/First Broken Gecko: Issue does NOT reproduce.
Gaia: 8defa5bf0cbce290c649e564b7f3ebe708e19b23
Gecko: 27ea1a450ed7

First Broken Gaia/Last Working Gecko: Issue DOES reproduce.
Gaia: 9fb8dff0277eb9ffe88f6efeb4426ec21c01395b
Gecko: 6b12800e0e46

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/8defa5bf0cbce290c649e564b7f3ebe708e19b23...9fb8dff0277eb9ffe88f6efeb4426ec21c01395b

Comment 20

[Jason Smith [:jsmith]]

So there's no gallery commits in the regression range. There are some window management commits however, so I'm guessing the regression is in that area.

Comment 21

[Jason Smith [:jsmith]]

Alive - Any ideas here? I see some window management patches in that commit range above.

Comment 22

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

https://bugzilla.mozilla.org/show_bug.cgi?id=963707 makes us to lock orientation according to the activity callee (camera app) and here it's gallery app.

These two bugs conflict each other: one rather to locked by the caller and another by the callee.
A workaround might be let gallery activity and camera activity to lock orientation on their own "after" the transition is ended. or, let gallery activity to support landscape mode.

Needinfo to David Flanagan.

Comment 23

[Preeti Raghunath(:Preeti)]

Blocking on 1.3 for bad picture view.

Comment 24

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #22)
> https://bugzilla.mozilla.org/show_bug.cgi?id=963707 makes us to lock
> orientation according to the activity callee (camera app) and here it's
> gallery app.
> 
> These two bugs conflict each other: one rather to locked by the caller and
> another by the callee.

This is so funny. needinfo? UX for a verdict on what exactly is expected.

Comment 25

[Stephany Wilkes]

Flagging Tiff with Jacqueline supporting.

Comment 26

[Tiffanie Shakespeare [:tif]]

Hey guys! I'm a little fuzzy on the steps to repro this bug. Is this issue being seen when sending the photo or receiving a photo in messenger?

Comment 27

[Jason Smith [:jsmith]]

(In reply to Tiffanie Shakespeare from comment #26)
> Hey guys! I'm a little fuzzy on the steps to repro this bug. Is this issue
> being seen when sending the photo or receiving a photo in messenger?

The bug is seen when prepping a MMS message to be sent. The user decides to create a MMS message, add a picture via the gallery, and then goes back to view the picture just added in landscape mode. When the picture is viewed, it is seen off-center with part of the picture cut off.

Comment 28

[Tim Guan-tin Chien [:timdream] (please needinfo)]

The question UX should answer is: when the user is presented with an inline activity dialog (e.g. "Pick a picture" from Gallery), do we lock/unlock the phone orientation according to the dialog, or we should not not do it and keep the orientation set by the foreground app?

Bug 963707 and this bug are conflicting on this behavior.

Comment 29

[Jason Smith [:jsmith]]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #28)
> The question UX should answer is: when the user is presented with an inline
> activity dialog (e.g. "Pick a picture" from Gallery), do we lock/unlock the
> phone orientation according to the dialog, or we should not not do it and
> keep the orientation set by the foreground app?
> 
> Bug 963707 and this bug are conflicting on this behavior.

I'm not sure if this is a question UX will be able to answer, as this feels like more like a technical design question. I'd probably ask Jonas on this one for his input.

Although we can't necessarily solve one bug and not the other, right? Don't we need a solution here that somehow solves both blocker bugs?

Comment 30

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Jason Smith [:jsmith] from comment #29)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from
> comment #28)
> > The question UX should answer is: when the user is presented with an inline
> > activity dialog (e.g. "Pick a picture" from Gallery), do we lock/unlock the
> > phone orientation according to the dialog, or we should not not do it and
> > keep the orientation set by the foreground app?
> > 
> > Bug 963707 and this bug are conflicting on this behavior.
> 
> I'm not sure if this is a question UX will be able to answer, as this feels
> like more like a technical design question. I'd probably ask Jonas on this
> one for his input.

Yes.

> Although we can't necessarily solve one bug and not the other, right? Don't
> we need a solution here that somehow solves both blocker bugs?

I am afraid that a solution like that would be considered as a hidden logic to app developers.
Note that if we decided to adopt the behavior of bug 963707 in Gaia System, this bug will then become a Gallery bug for it to adopt the new behavior.

Comment 31

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

My proposal would be let web activity to specify the orientation of the pages being opened as the activity.
For example, in gallery:
  "activities": {
    "pick": {
      "filters": {
        "type": ["image/*", "image/jpeg", "image/png"]
       },
      "disposition": "inline",
      "returnValue": true,
      "href": "/index.html#pick",
      "orientation": "default"
    }
  }

The reason of doing this is sometimes we may need activity page to have different orientation from the app launch page. I'd proposed this to :fabrice but he doesn't confirm to me.
Another reason is system app is the one controlling the orientation lock settings specified in the app manifest, now we lock the orientation when the app opening transition is ended, so if we let the app does this on its own we may break something because app/activity itself doesn't know when the transition is ended but only 'loaded' or 'foregrounded'.

Comment 32

[David Flanagan [:djf]]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #22)
> https://bugzilla.mozilla.org/show_bug.cgi?id=963707 makes us to lock
> orientation according to the activity callee (camera app) and here it's
> gallery app.
> 
> These two bugs conflict each other: one rather to locked by the caller and
> another by the callee.
> A workaround might be let gallery activity and camera activity to lock
> orientation on their own "after" the transition is ended. or, let gallery
> activity to support landscape mode.

I don't understand. Camera wanted to be locked in portrait mode, and you fixed that in 963707.  Gallery doesn't want to have its orientation locked at all, it wants to be free to rotate. I haven't tried this myself, but the screenshots shows it displayed in landscape, so it appears that gallery is able to rotate. Alive or Tim, could you explain the conflict between this bug and 963707 again?

Could this just be a bug in Gallery? Could it just be that somehow the initial activity transition is causing a resize event to be dropped so that Gallery thinks that it is in portrait mode when it is actually in landscape?

Can the user fix the display by switching orientation and then switching back?
> 
> Needinfo to David Flanagan.

Comment 33

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Please reply to David's comment above. Thanks.

Comment 34

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

(In reply to David Flanagan [:djf] from comment #32)
> (In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #22)
> > https://bugzilla.mozilla.org/show_bug.cgi?id=963707 makes us to lock
> > orientation according to the activity callee (camera app) and here it's
> > gallery app.
> > 
> > These two bugs conflict each other: one rather to locked by the caller and
> > another by the callee.
> > A workaround might be let gallery activity and camera activity to lock
> > orientation on their own "after" the transition is ended. or, let gallery
> > activity to support landscape mode.
> 
> I don't understand. Camera wanted to be locked in portrait mode, and you
> fixed that in 963707.  Gallery doesn't want to have its orientation locked
> at all, it wants to be free to rotate. I haven't tried this myself, but the
> screenshots shows it displayed in landscape, so it appears that gallery is
> able to rotate. Alive or Tim, could you explain the conflict between this
> bug and 963707 again?
> 
> Could this just be a bug in Gallery? Could it just be that somehow the
> initial activity transition is causing a resize event to be dropped so that
> Gallery thinks that it is in portrait mode when it is actually in landscape?

I think the problem here is gallery pick activity doesn't support landscape mode.
'But gallery "app" itself does'.
Maybe something in its css rules needs to be corrected.

> 
> Can the user fix the display by switching orientation and then switching
> back?
> > 
> > Needinfo to David Flanagan.

Comment 35

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #34)
> 
> I think the problem here is gallery pick activity doesn't support landscape
> mode.
> 'But gallery "app" itself does'.
> Maybe something in its css rules needs to be corrected.
> 

Yeah, that's what I meant to say in comment 30. I should have be more explicit.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #30)
> Note that if we decided to adopt the behavior of bug 963707 in Gaia System,
> this bug will then become a Gallery bug for it to adopt the new behavior.

Comment 36

[Hema Koka [:hema]]

Gallery guys have their hands full with blockers. (And this request for adopting to the new behavior is coming quite late for 1.3). Jason, do you know if we shipped with the same issue in 1.2 also? 

NI Johu to see if he is able to help

Comment 37

[Jason Smith [:jsmith]]

(In reply to Hema Koka [:hema] from comment #36)
> Gallery guys have their hands full with blockers. (And this request for
> adopting to the new behavior is coming quite late for 1.3). Jason, do you
> know if we shipped with the same issue in 1.2 also? 
> 
> NI Johu to see if he is able to help

1.2 wouldn't matter here, mainly because 1.2 isn't a partner facing release.

Comment 38

[David Flanagan [:djf]]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #34)
> 
> I think the problem here is gallery pick activity doesn't support landscape
> mode.
> 'But gallery "app" itself does'.
> Maybe something in its css rules needs to be corrected.
> 

I still don't fully understand this bug, and all of my devices are currently flashed with a build where everything crashes all the time, so I haven't reproduced it yet.  But if in the past the view activity was always invoked with orientation locked to portrait mode, it could be that the view activity does not have a resize handler to detect orientation changes.  If that is the case, then the fix is simple: just add a resize event handler, and call the resize method (or something with a similar name) on the media frame.  There should be examples of doing this in both Gallery and Camera.

Comment 39

[John Hu [:johnhu][:johu][:醬糊小弟]]

(In reply to Hema Koka [:hema] from comment #36)
> Gallery guys have their hands full with blockers. (And this request for
> adopting to the new behavior is coming quite late for 1.3). Jason, do you
> know if we shipped with the same issue in 1.2 also? 
> 
> NI Johu to see if he is able to help

Hema,

I will mentor our chens to check this bug.

Comment 40

[Sherman Chen [:chens] (inactive)]

I found this one is the same as bug 960215, media frame should receive resize event when window is resized. Apply this patch will fix: https://github.com/mozilla-b2g/gaia/pull/15512.patch
Also, should bug 960215 be flag as 1.3 affected? Following provides logs for the two cases. 

Before patch: 
E/GeckoConsole( 5167): Content JS LOG at app://system.gaiamobile.org/js/window.js:655 in aw_resize: -*- : enter appWindow resize

After patch:
E/GeckoConsole( 5167): Content JS LOG at app://system.gaiamobile.org/js/window.js:655 in aw_resize: -*- : enter appWindow resize
E/GeckoConsole( 5279): Content JS LOG at app://gallery.gaiamobile.org/js/frame_scripts.js:1776 in resize: -*- : enter media_frame resize


(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #39)
> (In reply to Hema Koka [:hema] from comment #36)
> > Gallery guys have their hands full with blockers. (And this request for
> > adopting to the new behavior is coming quite late for 1.3). Jason, do you
> > know if we shipped with the same issue in 1.2 also? 
> > 
> > NI Johu to see if he is able to help
> 
> Hema,
> 
> I will mentor our chens to check this bug.

Comment 41

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I am a bit sad that for all the ppl we needinfo'd no one actually realized this is already a fixed bug.

Chens, thanks for the investigation.

Comment 42

[Sherman Chen [:chens] (inactive)]

Attachment: Patch

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
[User impact] if declined:
[Testing completed]:
[Risk to taking this patch] (and alternatives if risky):
[String changes made]: