Closed Bug 995475 Opened 6 years ago Closed 6 years ago

[B2G][Camera]User attempt to adjust Zoom slider negatively affects Options icon performance intermittently

Categories

(Core :: Panning and Zooming, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33
Tracking Status
b2g-v1.4 --- affected

People

(Reporter: mclemmons, Assigned: kats)

References

()

Details

(Whiteboard: [1.4-camera-exploratory] [perf-reviewed][priority])

Attachments

(8 files)

User taps Camera App and slides on device screen to present the zoom slider. Repeated attempts to interact and cause the slider to appear and adjust causes a) intermittently the Options icon becomes non-responsive when selected or b) the Options icon becomes non-responsive other than the button becoming illuminated in blue but not opening the menu options or c) Options icon becomes responsive, the menu appears but selecting the icon to return to the Camera home screen is non-responsive or d) expected behavior occurs with the menu opening properly and returning to the main Camera screen when re-selected. 

Repro Steps:
1) Updated Buri to BuildID: 20140411000202
2) Tap Camera App and swipe on device screen in motion to cause the zoom slider to appear
3) Attempt movement of the zoom slider


Actual:
Intermittently, the Options icon becomes non-responsive when selected or the Options icon becomes non-responsive other than the button becoming illuminated in blue but not opening the menu options or Options icon becomes responsive, the menu appears but selecting the icon to return to the Camera home screen is non-responsive or expected behavior occurs with the Options menu opening and behaving appropriately.


Expected:
Options menu opens properly. There is no illumination of the Options icon with the menu not opening and interaction within the Options Menu takes user back to the Camera home screen successfully.

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140411000202
Gaia: 6c50349f41d40ba175ea0fc0c2c2cbd739ba7170
Gecko: 28b419f0e857
Version: 30.0a2
Firmware Version: v1.2-device.cfg

Notes:
Repro frequency: (25/100, 25%)
See attached: logcat, video = https://www.youtube.com/watch?v=iX5XWpsZMFw
Other: Video demonstrates repeated attempts and various outcomes (illuminated icon yet remains on Camera home page mode, non-responsive button on Camera home page as well as Options menu page). Used fingers and Stylus during video presentation to reproduce steps.
This issue does not reproduce on 1.3 Buri as the zoom feature and the options menu are not part of this build to attempt the STR from Comment 0.

Device: Buri 1.3 MOZ
BuildID: 20140409164003
Gaia: 62acb4b0e774b6709b8be400d849f807404bb21b
Gecko: 82e5ff16645a
Version: 28.0
Firmware version: v1.2-device.cfg
This issue does not reproduce on 1.4 Buri 3/26 Build. The Zoom slider and Options menu are not features within this build. 

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140326000201
Gaia: 7e705dd4718d528974d99ac31866318d7e201152
Gecko: 4889124accfa
Version: 30.0a2
Firmware Version: v1.2-device.cfg
The video here seems to be pretty poor UX - looks like it's easy to break the settings button when zoom is active for a certain period of time.
blocking-b2g: --- → 1.4?
I wonder if this is somehow related to Bug 986752. Even though it was marked as resolved and a patch landed last week, very strange behavior is still being observed with CSS :active states.
blocking-b2g: 1.4? → 1.4+
Here's a YouTube video showing the settings menu button getting "stuck" just by putting two fingers on the screen:

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

Using latest nightly build on Hamachi:

Gaia      f3abbd2d0a60f1a1618db93f8b1957cae6de379c
Gecko     https://hg.mozilla.org/mozilla-central/rev/215080b813a7
BuildID   20140414040203
Version   31.0a1
Just learned that Bug 976605 should be landing shortly which may resolve a lot of these CSS `:active` issues.
(In reply to Justin D'Arcangelo [:justindarc] from comment #6)
> Just learned that Bug 976605 should be landing shortly which may resolve a
> lot of these CSS `:active` issues.

Bug 976605 is not expected to be uplifted to 1.4, so we need a 1.4 specific solution to this issue.
Assignee: nobody → jdarcangelo
Whiteboard: [1.4-camera-exploratory] → [1.4-camera-exploratory] [perf-reviewed]
I cannot reproduce this on latest nightly build of 1.4 or master. The issue with CSS :active states I mentioned in Comment 5 still remains though. Can you check if you are still able to reproduce this on latest nightly builds?
Flags: needinfo?(mclemmons)
(In reply to Justin D'Arcangelo [:justindarc] from comment #8)
> I cannot reproduce this on latest nightly build of 1.4 or master. The issue
> with CSS :active states I mentioned in Comment 5 still remains though. Can
> you check if you are still able to reproduce this on latest nightly builds?

Able to reproduce this issue several times following the STR from Comment 0. In 15 attempts on 1.4 Buri, user able to 

a) intermittently the Options icon becomes non-responsive when selected - twice
b) the Options icon becomes non-responsive other than the button becoming illuminated in blue but not opening the menu options - twice
c) Options icon becomes responsive, the menu appears but selecting the icon to return to the Camera home screen is non-responsive - zero times.
d) expected behavior occurs with the menu opening properly and returning to the main Camera screen when re-selected - 11 times.


Environmental Variables:
Device: buri 1.4 MOZ
BuildID: 20140422000202
Gaia: 26432916d10434103a822f17be4624a342cadfba
Gecko: 211431128e5b
Version: 30.0a2
Firmware version: v1.2-device.cfg
Ok, I had only tried 3 or 4 times. Can we maybe nail down a more easily reproducible STR?
Unfortunately, the reported incident is very intermittent with a low repro rate. Using today's 1.4 and 1.5 builds, I was able to have a near similar 25% repro rate with the below steps:

1) Updated Buri to 20140422000202
2) Tap Camera App and swipe on device screen in motion to cause the zoom slider to appear
3) Attempt sliding movement of the zoom slider up or down 
4) Attempt tap of Options button
Flags: needinfo?(mclemmons)
Justin - Can you try again in reproducing this?
Flags: needinfo?(jdarcangelo)
I just flashed the latest 1.4 build and I still cannot reproduce this on my Hamachi. Question on the STR though. Do you have to kill the app in the task manager to retry? or do you simply zoom in and out a bunch and try repeatedly? I just zoomed in and out fast and slow, then attempted to open the settings menu about 20 times in a row and wasn't able to reproduce the issue shown in the video. I wasn't sure if I was supposed to kill the app in task manager in-between retries or not (I tried that a handful of times as well and still nothing).
Flags: needinfo?(jdarcangelo) → needinfo?(mclemmons)
For sake of full disclosure, here's the exact build I just tried on:

Gaia      b6a41ee9e2934fe9692da6fb1cb310cb759e9870
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/2e9abf89c087
BuildID   20140424000203
Version   30.0a2
Diego just observed that in the video, it appears as though the left-hand finger is maybe accidentally touching the viewfinder while the right-hand finger is trying to tap the settings menu button which is causing it to not want to open/close. Across all of Gaia, if you hold a finger down on the screen, you are unable to click on UI elements with a 2nd finger. For instance, in the Clock app, if you hold a finger down in the middle of the screen where the analog clock visualization is, you are unable to tap on the tabs at the bottom with a 2nd finger. I'm not certain this is the issue that's happening here, but it seems it might be. A follow-up bug will be filed for this "two-finger tapping" issue.
Marcia - Can you try to reproduce this?
Flags: needinfo?(mozillamarcia.knous)
Related:

Bug 1000985 - [B2G] 'click' events are not triggered if there is an existing touch on-screen
As Justin mentioned this is a gecko issue. On a two finger tap the click events are not delivered. On the video there's a two finger tap when interacting with the settings menu: Left finger on the left side of the screen and right finger on the settings button. The menu doesn't close because the click event is not delivered to the button. Can we bring the attention to the gecko team? This affects to all gaia apps.
(In reply to Justin D'Arcangelo [:justindarc] from comment #13)
> I just flashed the latest 1.4 build and I still cannot reproduce this on my
> Hamachi. Question on the STR though. Do you have to kill the app in the task
> manager to retry? or do you simply zoom in and out a bunch and try
> repeatedly? I just zoomed in and out fast and slow, then attempted to open
> the settings menu about 20 times in a row and wasn't able to reproduce the
> issue shown in the video. I wasn't sure if I was supposed to kill the app in
> task manager in-between retries or not (I tried that a handful of times as
> well and still nothing).

User is not killing the app in the task manager to retry. Rather zoom in and out several times and try repeatedly during testing. In the video https://www.youtube.com/watch?v=iX5XWpsZMFw, it was somewhat difficult to film the evidence, execute the two thumb maneuver to activate the zoom slider, have the slider move, and hold the device. However, at the 20 second mark of the first attempt, the left thumb was off the device screen prior to the selection of the option button. There is a small gap as the left thumb lifts slightly upward ever so slightly. If you would like me to provide a different video further demonstrating that, please needinfo me again.
Flags: needinfo?(mclemmons)
I think we need a better video that reproduce the problem where the left finger is clearly not part of the interaction while the settings menu is open. I still think that the video illustrates a gecko issue with the two finger tap that reproduce all across gaia (see attached videos)
Flags: needinfo?(mclemmons)
Attached video twoFingerTapCamera.MOV
Video illustrating the two finger tap problem on camera
Attached video twoFingerTapClock.MOV
Video illustrating the two finger tap problem on clock
https://www.youtube.com/watch?v=tF79gGDOurQ(In reply to Diego Marcos [:dmarcos] from comment #20)
> I think we need a better video that reproduce the problem where the left
> finger is clearly not part of the interaction while the settings menu is
> open. I still think that the video illustrates a gecko issue with the two
> finger tap that reproduce all across gaia (see attached videos)

Please see new video https://www.youtube.com/watch?v=tF79gGDOurQ.
 
Specifically, the 20 second mark and the 38 second mark where the left thumb was away from the device and the selection caused the behavior outlined in Comment 0 to appear.
Flags: needinfo?(mclemmons)
I *finally* got this to reproduce and in the process, I think I've nailed down a near 100% STR:

1.) use two-finger pinch-to-zoom gesture (not zoom bar)
2.) **quickly** release the gesture and tap the Settings button

NOTE: If you wait more than a half a second before tapping the Settings button, or if you use the Zoom Bar (one finger) it does not seem to reproduce.

Bug 997235 should fix this and has just landed. I'm going to try building latest Gecko from source and see if this issue is resolved from that patch.
Justin. In the first video that mclemmons posted we also see bug 1000985 when they try to close the settings menu with two fingers on the screen. The links below points to the exact point of the video:

https://www.youtube.com/watch?feature=player_detailpage&v=iX5XWpsZMFw#t=22
Depends on: 1000985
Leaving qawanted to retest on a 4/26 trunk build or later.
Keywords: qawanted
Flags: needinfo?(mozillamarcia.knous)
Issue reproduces on today's master build.

After invoking the zoom slider with two fingers, release both fingers, with zooming UI still on the screen, tapping on the Options button could sometimes make the Options button become highlighted but Options menu does not actually come up. Repro rate is low, about 1 in 10 attempts.
Repro rate is higher if does it quickly like comment 24 stated.

Tested on:
Device: Buri 2.0 MOZ
BuildID: 20140428040200
Gaia: f50d8a3504e0a57d371457c50a6ced333e20724d
Gecko: 4d926af89907
Version: 31.0a1
Firmware Version: v1.2-device.cfg
Keywords: qawanted
Attached file pull-request (master)
This patch uses touch events in place of `click` events which should prevent clicks from being detected when used in conjunction with multi-touch gestures.
Attachment #8414046 - Flags: review?(dmarcos)
Comment on attachment 8414046 [details] [review]
pull-request (master)

I like it a lot. It's very easy to understand. I guess is not as portable as Fastclick. Does it work on webkit/blink?
Attachment #8414046 - Flags: review?(dmarcos) → review+
Thanks! Yeah, it doesn't cover all of the special edge cases that FastClick covers, but it works well for our app. I haven't tested in other browsers yet.
Can you re-test this on master? I have landed patch for Bug 1000984 this morning and I seem to no longer be able to reproduce this. Thanks!
Flags: needinfo?(mclemmons)
Please note, the patch I have attached to this bug is *ONLY* to fix the issue of not being able to 'click' on buttons when two fingers are on-screen. However, since this is consistent behavior across all of Gaia, I'd rather not land this if we don't have to.
Keywords: qawanted
(In reply to Justin D'Arcangelo [:justindarc] from comment #31)
> Can you re-test this on master? I have landed patch for Bug 1000984 this
> morning and I seem to no longer be able to reproduce this. Thanks!

Unable to click on buttons when two fingers are on screen after over 20 attempts. 

However, continues to demonstrate intermittent unexpected behavior: including the illumination of the options button without opening, non-illumination of the options button and no movement to the options menu, and entering the options menu and reselection of the options button and nothing happening. The repro rate was low 20/100 = 20 percent. 

Environmental Variables:
Device: Buri 2.0 MOZ
BuildID: 20140430040206
Gaia: ddd3092cd9340a5b89d5bf715dbb0f8c8aad9634
Gecko: e19812f56952
Version: 32.0a1
Firmware version: v1.2-device.cfg
Flags: needinfo?(mclemmons)
Keywords: qawanted
The issue for the two fingers tap should be fixed with the patch attached to this bug. Justin, are we ready to land it?
Flags: needinfo?(jdarcangelo)
Diego: See Comment 32 -- I noticed some strangeness with the patch after using it for a while, you can test if you'd like. The bottom line is, the issue with the settings menu getting stuck in the highlighted mode is purely a gecko/rendering issue and I'm not sure we should be applying a hack at the application level to prevent it. We are doing nothing more that using CSS :active to show that highlighted state (NO JavaScript), so if anything we should be nailing down a STR with a higher repro rate and fixing in Gecko.
Flags: needinfo?(jdarcangelo)
So this means that bug 997235 hasn't solved the problem?
Flags: needinfo?(jdarcangelo)
I'm not sure if it's the same problem as Bug 997235. In that bug, the :active state got stuck when you put two fingers on-screen 100% of the time. Now, it seems as though there's only a 20% repro rate when tapping a button with an :active state *after* performing a multi-touch gesture. So, it may be related, but the patch for Bug 997235 definitely fixed the simple test case of two fingers on a button.
Flags: needinfo?(jdarcangelo)
Ok, there appears to still be an issue with CSS :active states when there are two fingers on-screen. Previously, in Bug 997235, the :active state would get stuck if you tapped with two fingers at the same time. Now, the issue seems to be when two fingers tap in rapid succession.

Video demonstration:
https://www.youtube.com/watch?v=YvbburJc76k

STR using the following test case:
http://jsbin.com/vorib

1.) Touch any button with Finger 1
2.) Before releasing Finger 1, touch the button with Finger 2
3.) Quickly release Finger 1
4.) Quickly release Finger 2

I think this explains why the Settings menu button is appearing to get "stuck" sometimes immediately following a pinch-to-zoom gesture using two fingers.

Additionally, note in the above test case, when you first load the page in the Browser app, single-tapping rapidly on any of the five buttons seems to be highly responsive (the highlighted state responds as quickly as you tap the buttons). However, after attempting to reproduce this issue with tapping with two fingers on-screen, at a certain point, the highlight state of the buttons does not respond very well. It regresses to the point where you can tap rapidly on the buttons and not see any highlighted state at app. This may be related to the issue in Bug 995532.

Setting NI? for Vivien since he worked on Bug 997235. It appears we still have some weirdness going on with CSS :active states in general.
Flags: needinfo?(21)
I should mention that in the video demonstration and the STR described in Comment 38, I was running the latest Gaia/Gecko nightly builds on master (2.0):

Gaia      8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko     https://hg.mozilla.org/mozilla-central/rev/b227a707080f
BuildID   20140501040203
Version   32.0a1
Also setting NI? for Botond who reviewed patch for Bug 997235 since Vivien seems to be out today. See Comment 38.
Flags: needinfo?(botond)
I'm responding for Botond here since I was just working on bug 1004516 which may be related.

I read through the bug here but frankly there's been a lot of discussion and STRs and such and I don't know what the current issue is. However, the "part 1" patch on bug 1004516 and the patch on bug 989416 fix issues that might be related, so whoever can reproduce whatever the latest issue is, please try with those patches to see if it is resolved. If it is not, please needinfo me and provide STR and expected/actual behaviour. (Or tag one of the previous comments that has this information with the "STR" tag).
Flags: needinfo?(botond)
NOTE: I have not yet tested patches for Bug 1004516 and Bug 989416, but in the meantime, I had come up with more findings that I'd like to document here:

Upon further investigation, I wasn't able to reproduce the issue with the test case from Comment 38 in the 1.4 branch, it only happens on master (2.0). However, I was still able to reproduce the original intermittent issue described by this bug in the Camera app in the 1.4 branch. As a last attempt to try and narrow down a better test case, I created a test case that has a running video behind some buttons (just like the Camera app does)... and that worked! I was able to reproduce this test case on *BOTH* v1.4 and master (2.0).

Test case w/ video playback:
http://jsbin.com/fuxec

STR for test case:
1.) Tap 2 fingers simultaneously anywhere on-screen (except for on a button)
2.) *Immediately* single-tap any of the buttons
3.) Observe the button's highlighted `:active` state to be stuck

This doesn't reproduce 100% of the time, but it seems fairly high.

A few items to note:
- I tested this without the video playing (paused) and was not able to reproduce
- The only JavaScript in this test case is attaching an empty event handler for the `touchstart` event to the body -- if this event handler is not attached, I am unable to reproduce

Tested on Hamachi v1.4:
Gaia      011330c45f575d5a87332e605be47f570faf10ca
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a9db863ae8c2
BuildID   20140501000200
Version   30.0

Tested on Hamachi master (v2.0):
Gaia      8873166797fecfa65c0afa644d2ebcc7d7cb4ed3
Gecko     https://hg.mozilla.org/mozilla-central/rev/b227a707080f
BuildID   20140501040203
Version   32.0a1
I start to wonder, is it really a release blocker? I tried 1.4 build(Git commit info:2014-05-02 11:29:54 fccb15d6) on Peak, and it looks okay. Not sure if I missed anything.
(In reply to Kevin Hu [:khu] from comment #43)
> I start to wonder, is it really a release blocker? I tried 1.4 build(Git
> commit info:2014-05-02 11:29:54 fccb15d6) on Peak, and it looks okay. Not
> sure if I missed anything.

It tooks me time but I'm able to reproduce with the testcase from Justin. Honestly it's hard to do and so I don't think that's a blocker, while I agree that it is an annoying bug that break the rule of "1 highlight == 1 action".
Flags: needinfo?(21)
I also agree with Kevin and Vivien that this should not block. If anything, we should open a follow-up bug with the test case in Comment 42 since this bug was tracking it as a Camera issue but that is not really the case.
Let me have Marcia look at this first.

When I analyzed this bug originally, it appeared that zooming was breaking the settings button, but it appears the video might be deceiving the actual truth of reproduction here.
Flags: needinfo?(mozillamarcia.knous)
Thank you, Jason.
blocking-b2g: 1.4+ → 1.4?
From discussing with Marcia in person - we think the bug's original definition lost it's context, so we need to check if the original bug as filed is still reproducing.

I'm adding qawanted to check if the original STR in comment 0 still reproduces.
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #48)
> From discussing with Marcia in person - we think the bug's original
> definition lost it's context, so we need to check if the original bug as
> filed is still reproducing.
> 
> I'm adding qawanted to check if the original STR in comment 0 still
> reproduces.

Original STR in Comment 0 reproduces reported issue on the latest 1.4 build intermittently. 

On 1.4, the breakdown of results (50 attempts = 9 repros, 41 non-repros):

Options icon becomes non-responsive when selected = 4 times
Options icon becomes illuminated in blue but not opening the Option menu = 2 times 
Options Menu appears but selecting the icon to return to Camera home screen is non-responsive = 3 times
Expected behavior occurs with the Options menu opening and behaving appropriately = 41 times

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140507000202
Gaia: bac831d2ebc567f0939e41fbd8a4c15ef183b954
Gecko: 8040ccd0d4b1
Version: 30.0
Firmware Version: v1.2-device.cfg
Keywords: qawanted
comment 49 concludes that the original bug as filed under the same repro rate still reproduces, which means this still remains as a blocker for the original reason why we blocked on it.
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(mozillamarcia.knous)
I would like clarification as to if the STR followed in Comment 49 was using the Zoom Bar slider (one touch) versus using the pinch gesture (two touches). The original STR in Comment 0 says "Attempt movement of the zoom slider".

Using the same latest 1.4 build as described in Comment 49 on Hamachi, I was not able to reproduce using the Zoom Bar slider out of 20 attempts. However, using the pinch gesture, I was able to get the Settings button to get stuck 2 times out of 20 attempts.
Flags: needinfo?(mclemmons)
(In reply to Justin D'Arcangelo [:justindarc] from comment #51)
> I would like clarification as to if the STR followed in Comment 49 was using
> the Zoom Bar slider (one touch) versus using the pinch gesture (two
> touches). The original STR in Comment 0 says "Attempt movement of the zoom
> slider".
> 
> Using the same latest 1.4 build as described in Comment 49 on Hamachi, I was
> not able to reproduce using the Zoom Bar slider out of 20 attempts. However,
> using the pinch gesture, I was able to get the Settings button to get stuck
> 2 times out of 20 attempts.

The STR followed in Comment 49 was using the Zoom Bar slider in all repro attempts.
Flags: needinfo?(mclemmons)
Marcia - Can you check this to see if you can reproduce this using mclemmons's STR?
Flags: needinfo?(mozillamarcia.knous)
mclemmons: The video in Comment 0 shows this happening when the camera is in video mode - is this happening in camera mode as well? Also does it only occur with Buri device? I tried the STR on Open C and I wasn't able to reproduce.
Flags: needinfo?(mozillamarcia.knous) → needinfo?(mclemmons)
(In reply to Marcia Knous [:marcia - use needinfo] from comment #54)
> mclemmons: The video in Comment 0 shows this happening when the camera is in
> video mode - is this happening in camera mode as well? Also does it only
> occur with Buri device? I tried the STR on Open C and I wasn't able to
> reproduce.

This is occurring as well in camera mode. Following the STR on today's 1.4 Buri, user able to reproduce this issue at a rate of 10/50 = 20 percent. 

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140512000204
Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b
Gecko: ec24f847e7c0
Version: 30.0
Firmware Version: v1.2-device.cfg

This is also occurring on 1.4 Flame, today's build. However, following the STR witnessed a repro rate of 1/50 = 2 percent. Attached is the 1 occurrence screen capture on Flame.

Environmental Variables:
Device: Flame 1.4 MOZ
BuildID: 20140512000204
Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b
Gecko: ec24f847e7c0
Version: 30.0
Base Image: v10F-3
Flags: needinfo?(mclemmons)
Attached image Flame example
I tried reproducing this yesterday on Buri and I wasn't able to get a 20% repro rate (I had issues reproducing it at all). I think we need to update the summary to reflect the fact that the options button is remaining in the pressed state (and also non-functional?) - let's make sure we are clear in the bug about exactly what is happening - mclemmons can you confirm this is a summary of the current behavior:

(1) When playing around with zoom slider, options button sometimes remains in "pressed" state (20% repro)
(2) Options button is intermittently non functional when in this state.
(3) Issue has been reproduced on Flame and Buri Devices so far
Flags: needinfo?(mclemmons)
(In reply to Marcia Knous [:marcia - use needinfo] from comment #57)
> I tried reproducing this yesterday on Buri and I wasn't able to get a 20%
> repro rate (I had issues reproducing it at all). I think we need to update
> the summary to reflect the fact that the options button is remaining in the
> pressed state (and also non-functional?) - let's make sure we are clear in
> the bug about exactly what is happening - mclemmons can you confirm this is
> a summary of the current behavior:
> 
> (1) When playing around with zoom slider, options button sometimes remains
> in "pressed" state (20% repro)
> (2) Options button is intermittently non functional when in this state.
> (3) Issue has been reproduced on Flame and Buri Devices so far

I would slightly amend this summary:

1. The menu appears but selecting the icon to return to the Camera home screen is non-responsive intermittently
2. When playing around with zoom slider, options button sometimes remains in "pressed" state 
3. Intermittently the Options icon becomes non-responsive when selected (not in "pressed blue" state)
4. Issue has been reproduced on Flame and Buri Devices so far
Flags: needinfo?(mclemmons)
The real issue here has nothing to do with Camera API, zoom or even the slider control. This is a Gecko issue that needs to be looked into by someone with GFX knowledge. Any time you have video playback occurring behind elements (buttons) that have a CSS :active (highlight) state, you will end up with visually "stuck" buttons that behave strangely and appear unresponsive. The test case I provided in Comment 42 illustrates this plainly:

http://jsbin.com/fuxec

STR for test case:
1.) Place 2 fingers anywhere on-screen (except for on a button)
2.) Release 2 fingers and tap any of the buttons (sometimes you may need to tap 2-3 times to observe the issue)
Assignee: jdarcangelo → nobody
This is important but not a blocker. How do we demote it?

Can we bring anyone from GFX to look at it?
Flags: needinfo?(hkoka)
I would be the GFX person responsible for looking into this, if it is a GFX issue. I previously requested clear STR in comment 41, but it looks to me like that's still under debate. Since comment 42/59 has a simplified test case I'll investigate using that for now.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #61)
> I would be the GFX person responsible for looking into this, if it is a GFX
> issue. I previously requested clear STR in comment 41, but it looks to me
> like that's still under debate. Since comment 42/59 has a simplified test
> case I'll investigate using that for now.

Thanks for investigating!

Hema
Flags: needinfo?(hkoka)
Here is a video demonstration of the test case from Comment 42 and Comment 59:

https://www.youtube.com/watch?v=EzYzcKHigeg
I'm going to unblock this mainly because this seems quite hard to hit (especially on Flame).
blocking-b2g: 1.4+ → ---
I am leaving this in the priority bucket based on the 20% reproduction rate on 1.4 Buri leading to poor user experience. 

Removing 1.4 blocker and based on comment 59 moving it to graphics bucket. 

Thanks
Hema
Component: Gaia::Camera → Graphics
Product: Firefox OS → Core
Whiteboard: [1.4-camera-exploratory] [perf-reviewed] → [1.4-camera-exploratory] [perf-reviewed][priority]
I worked together with MClemmons and we concluded that the steps provided in comment 59 do result in the same issues that this bug was initially logged about, mainly of the icon becoming highlighted but not actually opening.

This was tested on a Buri device running the latest master build.

Environmental Variables:
Device: Buri
BuildID: 20140513034257
Gaia: de1c755411949b50ae395b42e124af215ed9b702
Gecko: 7f5a8526b55a
Version: 32.0a1
Base Image: V1.2-device.cfg
Assignee: nobody → bugmail.mozilla
Component: Graphics → Panning and Zooming
I investigated this problem a little, and it does appear to be an APZ problem. It was really hard to repro on my Hamachi but I managed to catch it once with AEM logging enabled, so I'm saving the log here. At the end of the log the button remains in the highlighted state.

The log shows that we are often not in the state we think we are, probably because of underlying state management problems in our gesture detection code. I have filed bug 1009733 for the underlying issues.

However there also appears to be a bug in the ActiveElementManager in that it doesn't clear the active state on touch up, and doing that may fix this problem. I can post a patch but because I was only able to reproduce this once out of ~10 minutes of trying, I don't think that I can confirm the fix reliably, I might need somebody else to do that.
Attached patch PatchSplinter Review
Justin, can you try this gecko patch to see if it fixes the problem for you?
Attachment #8421929 - Flags: review?(botond)
Attachment #8421929 - Flags: feedback?(jdarcangelo)
Comment on attachment 8421929 [details] [diff] [review]
Patch

Review of attachment 8421929 [details] [diff] [review]:
-----------------------------------------------------------------

Do we need a corresponding fix to BEP.js for 1.4? As far as I can tell, BEP.js doesn't call resetActive() in this situation either.

::: gfx/layers/apz/util/ActiveElementManager.cpp
@@ +120,5 @@
>    CancelTask();
>    if (aWasClick) {
>      SetActive(mTarget);
> +  } else {
> +    ResetActive();

It might be worth adding a comment mentioning in what scenario this is needed: when mCanBePan was false on touch-start and therefore we set the active state right away, but the touch still wasn't a click (for example the user moved their finger as if panning, but the content was not pannable).
Attachment #8421929 - Flags: review?(botond) → review+
Comment on attachment 8421929 [details] [diff] [review]
Patch

Review of attachment 8421929 [details] [diff] [review]:
-----------------------------------------------------------------

I was still able to reproduce with the test case, but the frequency was not nearly as often.
Attachment #8421929 - Flags: feedback?(jdarcangelo) → feedback-
:(

In that case can you please apply this patch which enables some logging, and reproduce the problem? Please log using "adb logcat -v time" to include timestamps, and stop the log at the point where the element is perma-active.

It would be better to apply this on top of the previous patch that I posted, so that we isolate the cause of the problem you're still seeing.
Flags: needinfo?(jdarcangelo)
Assignee: bugmail.mozilla → nobody
I think the issue of stuck active state is crippling in other places: 

https://bugzilla.mozilla.org/show_bug.cgi?id=1016784#c11

https://bugzilla.mozilla.org/show_bug.cgi?id=1016784#c15

Kats, what do you need to determine what's going on here?
Flags: needinfo?(bugmail.mozilla)
Blocks: 1016784
See comment 71
Flags: needinfo?(bugmail.mozilla)
Landing this patch since it fixes an actual logic error in the code. This bug is now hella-confusing so if there are other issues please file a follow-up bug with clear STR.

https://hg.mozilla.org/integration/mozilla-inbound/rev/20ea2bb7e90d
Assignee: nobody → bugmail.mozilla
Flags: needinfo?(jdarcangelo)
https://hg.mozilla.org/mozilla-central/rev/20ea2bb7e90d
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.