Closed Bug 991367 Opened 10 years ago Closed 10 years ago

[B2G][Gallery] The Camera button remains active beneath the Pause video button when playing a video in the gallery.

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, b2g-v1.3 unaffected, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
1.4 S5 (11apr)
blocking-b2g 1.4+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: jmitchell, Assigned: justindarc)

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

Attached file logcat.txt
Description:
When you select a video from the gallery it fills the screen but has a control bar at the bottom (camera, edit, share, info, delete). When you push play (center screen) on the video the control bar is replaced with a Pause button and a time scrubber. Pressing toward the left side of the pause button will trigger both the pause functon and the camera button that the pause button overlays.

Repro Steps:
Precondition: Have a video on the device or record one.
1) Update a buri to BuildID: 20140401000202
2)Launch gallery
3)Select a Video
4)Tap on Play
5) Tap on the Pause button toward the left side
Actual:
Camera App is launched
Expected:
Movie will be paused, camera app button under pause icon will not function

1.4 Environmental Variables:
Device: buri 1.4 MOZ
BuildID: 20140401000202
Gaia: 216cc2e5c8692ba71aa78a9f27e84e9da27952b8
Gecko: 9223243c65a2
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Repro frequency: 50%
See attached: logcat.txt, PauseButton.mp4

Notes:
Does NOT repro on 1.3
1.3 Environmental Variables:
Device: buri 1.3 MOZ
BuildID: 20140401004003
Gaia: 24f562fce468fc948ac9e6185e002c23350cb9ee
Gecko: 0adf24a785f2
Version: 28.0
Firmware Version: v1.2-device.cfg
Attached video PauseButton.mp4 (obsolete) —
This also occurs when playing the video in landscape view.
Attached video PauseButtonMuted.mp4
Forgot to Mute my first video attachment, sorry.
Attachment #8400947 - Attachment is obsolete: true
Might be a gecko regression with touch events. Seems like we're doing the wrong behavior here.
blocking-b2g: --- → 1.4?
blocking-b2g: 1.4? → 1.4+
thats odd behavior. we ran into something similar with multi-touch on screen...could possibly related to touch event issue here: https://bugzilla.mozilla.org/show_bug.cgi?id=986752

thanks
hema
I can confirm both the video pause button tap event and the camera button (fullscreen-camera-button-tiny) onclick event are generated when following the STR. Although, for me only in landscape orientation. I have not been able to reproduce in portrait.
Assignee: nobody → rnicoletti
Status: NEW → ASSIGNED
Attached file Tap event logging
I am able to reproduce in both portrait and landscape. I've found it is the vertical touch position that is important, not the horizontal. I can consistently reproduce by tapping at the bottom of the pause button. For example, in portrait, when tapping at x=8, y=435 there is no camera event. But when tapping at x=68, y=476 we get both the pause and camera events.

The attachment has logging of many tap events showing the x and y positions and whether one or both events were triggered.
QA Contact: tnguyen
Waiting for regression window to help determine if a gecko or gaia issue. Tony, can you get a regression window for this issue?
Flags: needinfo?(tnguyen)
This issue looks to have started reproducing on the 01/09/14 Master (1.4) build.

- Last Working -
Device: Buri Master (1.4) MOZ RIL
BuildID: 20140108040200
Gaia: b7a7191f761933fd4878227488c75d09f5ba890c
Gecko: cf2d1bd796ea
Version: 29.0a1
Firmware Version: v1.2-device.cfg

- First Broken -
Device: Buri Master (1.4) MOZ RIL
BuildID: 20140109040203
Gaia: 47206ac66b084c6f6c4503a3b10d0e0760df2b6f
Gecko: 9409405e0739
Version: 29.0a1
Firmware Version: v1.2-device.cfg


**This looks to be a gaia issue.**
last working gaia/first broken gecko = NO REPRO
Gaia: b7a7191f761933fd4878227488c75d09f5ba890c
Gecko: 9409405e0739

first broken gaia/last working gecko = REPRO
Gaia: 47206ac66b084c6f6c4503a3b10d0e0760df2b6f
Gecko: cf2d1bd796ea

Push log: https://github.com/mozilla-b2g/gaia/compare/b7a7191f761933fd4878227488c75d09f5ba890c...47206ac66b084c6f6c4503a3b10d0e0760df2b6f
Flags: needinfo?(tnguyen)
QA Contact: tnguyen → mvaughan
bug 951812 is in the range here.
Looking at the commits in the regression window from comment #9, I don't see anything likely to cause this behavior. I backed out bug 951812 and was not surprised that doing so had no affect; that gallery code is not executed in the STR. Also, I am able to reproduce using the "last working build" from comment #9 by tapping on the very bottom of the pause button. Similarly, I am able to reproduce using 1.4, BuildID 20140101040201. I haven't been able to reproduce using 1.3, BuildID 20140401004003.

Mathew, can you try again to find the regression range? As I mentioned, when I have been able to reproduce it is by pressing the very bottom of the pause button.
Flags: needinfo?(mvaughan)
After further investigation, I've found this to be an APZ related issue. However the issue doesn't look to have started reproducing until the 12/13/13 Master (1.4) build.

- Last Working -
Device: Buri Master (1.4) MOZ RIL
BuildID: 20131212040203
Gaia: 8952898bbc98dd31e25b647203791cf129867ff1
Gecko: 1ad9af3a2ab8
Version: 29.0a1
Firmware Version: v1.2-device.cfg

- First Broken -
Device: Buri Master (1.4) MOZ RIL
BuildID: 20131213040203
Gaia: 390b313a254a947d12e3cdbcde19d7d1619ff63c
Gecko: 8b5875dc7e31
Version: 29.0a1
Firmware Version: v1.2-device.cfg

**This looks to be a gecko issue.**
last working gaia/first broken gecko = REPRO
Gaia: 8952898bbc98dd31e25b647203791cf129867ff1
Gecko: 8b5875dc7e31

first broken gaia/last working gecko = NO REPRO
Gaia: 390b313a254a947d12e3cdbcde19d7d1619ff63c
Gecko: 1ad9af3a2ab8

Gecko push log: http://hg.mozilla.org//mozilla-central/pushloghtml?fromchange=1ad9af3a2ab8&tochange=8b5875dc7e31

In case this is actually a gaia issue, here's its push log: https://github.com/mozilla-b2g/gaia/compare/8952898bbc98dd31e25b647203791cf129867ff1...390b313a254a947d12e3cdbcde19d7d1619ff63c
Flags: needinfo?(mvaughan)
Can we check if this is reproducing with APZC disabled on 1.4?

Can we reconfirm this isn't happening on 1.3?
Keywords: qawanted
Given this appears to be a gecko issue, I'm relinquishing the bug.
Assignee: rnicoletti → nobody
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → jdarcangelo
Attached file pull-request (master)
Attachment #8404863 - Flags: review?(dflanagan)
Comment on attachment 8404863 [details] [review]
pull-request (master)

Justin,

I don't have any particular complaints about the code, but I don't understand what it is doing and why it works to fix this bug, so I'm giving r- just to get more explaination.

Given that its just been decided above that this is a gecko issue, please explain here (and possibly in comments in your patch) what your patch is changing and why it solves this problem.

Specific questions I have are:

1) Do you consider this a gaia-based workaround to an underlying gecko bug, or is this just a gaia bug that you're fixing?

2) If this is just a workaround, do you have any insights into the nature of the gecko bug, because if there is one we'll presumably want to file a followup for it.

3) Why are you using transition-delay in the patch? Is that needed for the workaround, or is it just there to improve the visual effect somehow?

4) Given that the toolbar is being translated off screen, why do you also need to animate the visibility?

That last question leads me to speculate a bit... Since others have suggested above that this is related to APZC, I suppose that scrolling something so that it is just offscreen means it might be hidden, but is still rendered since the viewport is bigger than the screen.  Adding that to the touch target fluffing that goes on (I think) makes me wonder if what's happening is that the camera button is sliding down but remaining active and is being activated thanks to the fluffing code.

It that is the case, we could probably confirm it by translating the toolbar down 9rem instead of 4.5 rem so it is further off the screen.  I think that would be an interesting experiment.

But it also seems like there ought to be some way in CSS to define this video player screen to indicate that it has a fixed size and will never be scrolling.  Basically: why is the AZPC code even relevant here since there is nothing to zoom or pan.

I'd like to set needinfo for someone who understands AZPC and can help diagnose this, but I'm not even sure who that would be...
Attachment #8404863 - Flags: review?(dflanagan) → review-
QA Contact: mvaughan → rkuhlman
Comment on attachment 8404863 [details] [review]
pull-request (master)

Updated PR as per our offline discussion to add explanation that this is a workaround for what is a potentially larger issue. Carrying R+ over from our discussion.
Attachment #8404863 - Flags: review- → review+
Landed on master:

https://github.com/mozilla-b2g/gaia/commit/fad7c4d2c735549c7d1339168e4b23d1e41be3a7
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Removing qawanted for now per comment 18, but we will test the fix on Monday (4/14).
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: