989087 - [Camera] Snapshot button is unreachable during call

Status: RESOLVED FIXED

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

Description

[Diego Wilson [:diego]]

Attachment: Screen recording

STR:

1. Open camera
2. Take snapshots
3. Receive and accept call
4. While in call press home button and re-open camera

Result: The whole screen is offset down to fit in the call status, cutting off the bottom buttons.

Comment 1

[Diego Wilson [:diego]]

Hi David,

Do you see this too on your hardware?

Comment 2

[Jason Smith [:jsmith]]

QA Wanted - Can we confirm this on a 1.4 Buri device?

Comment 3

[David Flanagan [:djf]]

Tested with a nightly build on Hamachi. The viewfinder shifts down but the shutter button is big enough that I can still use it.  The shutter button sound is not played when I take a picture, but I suppose that is expected since a call is in progress.

When the new controls are uplifted to 1.4, I'd expect this bug to be minor and the phone will still be usable while a call is in progress.  I don't recommend that we block on this.

I'd forgotten that this is how pending calls are handled. I wonder if we get a resize event when that call-in-progress bar is there...  The camera visual design (and the selection of the preview size, etc) is strongly tied to the size of the screen, so it is not clear what the right thing to do is when the available screen size is reduced because there is a call in progress.

Hmm: I notice that if I launch camera for the first time while a call is in progress, then it looks right.
But if I then end the call, the viewfinder is too small, and there are black bars at the top and bottom.  So we really aren't handling screen size changes correctly.

All this testing is done on a barely-stable nightly build on hamachi. Lots of app and OS crashes happening during the testing, so nothing seems right here.

Setting needinfo for the camera team and our UX designer.  Perhaps all we really need to do here is set the control positions using bottom instead of top.  Or maybe there is a system app bug and our window is not being resized but just shifted down.  Or maybe there is a bug in the new CSS vw, vh units and those aren't working in this case.  

Also qa-wanted to find out if this is a recent regression (maybe a problem in the system app?) or something that goes way back

Comment 4

[Josh Schmitt [Joshs]]

Issue repros on 1.4 Buri

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140326000201
Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: V1.2-device.cfg

Comment 5

[Jason Smith [:jsmith]]

Can we verify this doesn't reproduce on 1.3?

Comment 6

[Wilson Page [:wilsonpage]]

First impression is, this issue looks out of scope of camera. If the hight of the window was reduced due to the call status bar, our app controls would remain at the bottom of the screen.

It appears the call status bar is actually displacing the camera app's window, causing it to overflow the viewport.

I'm guessing the desired behaviour would be to resize the app's window to accommodate the status bar. If that were the case, we probably would have to make some resize adjustments to the viewfinder positioning.

IMO the call status bar should be tucked inside the pull-down notifications tray to avoid every FXOS app having to work around this resizing. I'd imaging bugs would crop up across the OS.

This reminds me of working with Blackberry playbooks whereby keyboards would shrink the viewport instead of overlay. This is an app developer's nightmare, as the opening of the keyboard can suddenly activate height/aspect related media queries.

This is likely out of scope of this issue, but I think the OS should avoid interfering with the app's territory at all cost.

Comment 7

[Amy Lee [:amylee] UX]

Flagging Tiff on this as well

Comment 8

[Amy Lee [:amylee] UX]

Hi, 

Can someone attach a screenshot of this issue? I don't have a sim card on hand.

Comment 9

[Inder]

Diego, can you please attach a video/screenshot of the issue.

Comment 10

[Diego Wilson [:diego]]

See https://www.dropbox.com/s/omiydhun4cmx8lv/cr-639027.3gp which I refer to in the attachment

Comment 11

[Josh Schmitt [Joshs]]

(In reply to Jason Smith [:jsmith] from comment #5)
> Can we verify this doesn't reproduce on 1.3?

Following the original repro steps in comment 0, I am unable to repro this issue on the latest 1.3 build.

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140328004002
Gaia: 523196662f4d19c7898d5f4773da020c39cfe57e
Gecko: aa1d48ab3715
Version: 28.0
Firmware Version: V1.2-device.cfg

Comment 12

[Jason Smith [:jsmith]]

Can we see what happens on 1.5 & include a screenshot as a point of comparison? That will analyze what the impact of this bug is with the new camera work.

Comment 13

[Josh Schmitt [Joshs]]

Attachment: Camera.png

I was able to reproduce this issue on the latest 1.5. I have also included a screenshot of 1.5.

Environmental Variables:
Device: Buri 1.5 MOZ
BuildID: 20140331040200
Gaia: 26839cb46f856d610b192f5655a8c38a6bfe0829
Gecko: d8e8f13bd4ae
Version: 31.0a1
Firmware Version: V1.2-device.cfg

Comment 14

[Jason Smith [:jsmith]]

Does this problem with the bottom toolbar getting pushed bar show up in other Gaia apps (e.g. Clock/Calendar would be good to test)?

Comment 15

[Tiffanie Shakespeare [:tif]]

(In reply to Jason Smith [:jsmith] from comment #14)
> Does this problem with the bottom toolbar getting pushed bar show up in
> other Gaia apps (e.g. Clock/Calendar would be good to test)?

That's a good question. I don't have a SIM so I can't do any call testing to see the behaviours, but looking at Diego's video it's clearly a bug. As Wilson pointed out, ideally we could resize the window so both the return to call and camera buttons are usable at the same time. But I get that it might become a nightmare.

I'm not totally pro hiding the return to call button in notifications as it increases the number of steps and amount of effort/time to get back to the dialer. And when you need to get back to the dialer, you need to do so ASAP. Think of needing to unmute yourself during a meeting to respond to a question - it has to be quick.

Granted, the odds of you snapping photos while being muted on a call are low, that doesn't mean we shouldn't fix it, but back to Jason's point we need to first know if this impacts all apps or just camera before we can decide on an ideal solution.

That was really long winded for - need more info about the behaviour :)

Comment 16

[Josh Schmitt [Joshs]]

(In reply to Jason Smith [:jsmith] from comment #14)
> Does this problem with the bottom toolbar getting pushed bar show up in
> other Gaia apps (e.g. Clock/Calendar would be good to test)?

I tested multiple apps, Clock, Calendar, Contacts, Messaging, Usage, Gallery.

What I noticed is that the UI will be pushed down for the majority of the apps however, the Gallery app is the app where the UI was pushed down to where I could not use the buttons.

Comment 17

[Jason Smith [:jsmith]]

(In reply to Josh Schmitt from comment #16)
> (In reply to Jason Smith [:jsmith] from comment #14)
> > Does this problem with the bottom toolbar getting pushed bar show up in
> > other Gaia apps (e.g. Clock/Calendar would be good to test)?
> 
> I tested multiple apps, Clock, Calendar, Contacts, Messaging, Usage, Gallery.
> 
> What I noticed is that the UI will be pushed down for the majority of the
> apps however, the Gallery app is the app where the UI was pushed down to
> where I could not use the buttons.

Could you get a screenshot with this bug in the gallery app?

Comment 18

[Josh Schmitt [Joshs]]

Attachment: Gallery_UI.png

I have attached a picture of the Gallery app which includes both working/broken UI.

Comment 19

[Jason Smith [:jsmith]]

(In reply to Josh Schmitt from comment #18)
> Created attachment 8400095 [details]
> Gallery_UI.png
> 
> I have attached a picture of the Gallery app which includes both
> working/broken UI.

Ok - that looks bad. That proves this is a window management problem, as this present across multiple apps. So I'm blocking on this.

Comment 20

[Josh Schmitt [Joshs]]

Note: This regression window occurred between the 1.3-1.4 split.

Tinderbox:

Last Working
Environmental Variables:
Device: Buri MOZ
BuildID: 20131210040206
Gaia: c952e2756c03eceb4de6a3eba15651741a62f9e8
Gecko: df82be9d89a5
Version: 29.0a1
Firmware Version: V1.2-device.cfg

First Broken:
Environmental Variables:
Device: Buri MOZ
BuildID: 20131211040203
Gaia: 6415b8b44068596404c10365394544e94edd5ce5
Gecko: 12ea03a70243
Version: 29.0a1
Firmware Version: V1.2-device.cfg

Last Working Gecko First Broken Gaia: Issue DOES repro
Gaia: 6415b8b44068596404c10365394544e94edd5ce5
Gecko: df82be9d89a5

First Broken Gecko Last Working Gaia: Issue does NOT repro
Gaia: c952e2756c03eceb4de6a3eba15651741a62f9e8
Gecko: 12ea03a70243

Gaia Pushlog:
https://github.com/mozilla-b2g/gaia/compare/c952e2756c03eceb4de6a3eba15651741a62f9e8...6415b8b44068596404c10365394544e94edd5ce5

Comment 21

[Jason Smith [:jsmith]]

I have a very strong feeling that this was caused by bug 907013.

Alive - What do you think?

Comment 22

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

Seems resizing issue, taken.

Comment 23

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

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

Patch for master

Comment 24

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

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

The code itself is alright, but I think we need a test suite for all the cases to prevent more regressions.

Comment 25

[Preeti Raghunath(:Preeti)]

Alive,

ni on you for having this on your radar.

Comment 27

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

Add a integration test and get green
https://github.com/mozilla-b2g/gaia/commit/617635d828ec039b17bf0c3408921ec92d14a73b

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Needs rebasing for v1.4.

Comment 29

[Hema Koka [:hema]]

clearing ni flags

Comment 30

[Ryan VanderMeulen [:RyanVM]]

Still needs a branch patch.

Comment 31

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

I will make the 1.4 patch.

Comment 32

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

https://github.com/mozilla-b2g/gaia/pull/18269
Waiting travis run.

Comment 33

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

Green, merged.
v1.4
https://github.com/mozilla-b2g/gaia/commit/e5b6b03450d7c6fc7a88d503a2dea3f38efa5006

Comment 34

[Yeojin Chung [:YeojinC]]

New test case needs to be added. There is no existing test case.

Comment 35

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case has been created which can be found here:

https://moztrap.mozilla.org/manage/case/14107/