It is possible to get an element with an `:active` CSS state defined to be "stuck" in the `:active` state by placing multiple touches on-screen at the same time and moving them around before releasing.

let's keep qawanted on the blocking bug here to figure out if this reproduces, as that bug has the end-user STR

Demonstration of some basic CSS styles on BUTTON elements that can be used to reproduce the bug. Using a single finger and tapping on any button in the demo works as expected. Placing multiple fingers on the buttons will cause the `:active` state to remain applied.

QA Wanted - Can we use the test case included here to see if we can reproduce on 1.4?

This issue reproduces on the 03/26/14 1.4 build on a Buri using the attached test case. Device: Buri v1.4 MOZ RIL BuildID: 20140326000201 Gaia: 7e705dd4718d528974d99ac31866318d7e201152 Gecko: 4889124accfa Version: 30.0a2 Firmware Version: v1.2-device.cfg Attached a video of the issue reproducing.

Attached a logcat for when the issue reproduces.

Okay - can we check if this happens on 1.3?

This is probably an issue in the active element handling code in BrowserElementPanning.js and/or TabChild.cpp. It may be fixed by bug 976605 - Botond, since you're working on that one can you take a look at this too? It might be worth fixing this separately for a cleaner uplift to 1.4.

Blocks a partner app & camera app, so I'm blocking this. Before we consider going after the C++ solution here, let's see if we can find out what caused this regression.

TINDERBOX REGRESSION WINDOW: Device: Buri v1.4 MOZ RIL BuildID: 20140215032047 Gaia: 8ac5dc6b76709e742cb923c58d1f4b415b3e08fb Gecko: f6ab28f98ee5 Version: 30.0a1 Firmware Version: v1.2-device.cfg Device: Buri v1.4 MOZ RIL BuildID: 20140215095648 Gaia: 8ac5dc6b76709e742cb923c58d1f4b415b3e08fb Gecko: 9394396013a8 Version: 30.0a1 Firmware Version: v1.2-device.cfg **This looks to be a gecko issue since gaia does not change between these two builds.** Push log: http://hg.mozilla.org//mozilla-central/pushloghtml?fromchange=f6ab28f98ee5&tochange=9394396013a8

Likely regressed by bug 972081.

Over to Panning and Zooming to track down whether this was caused by bug 972081.

Backing out that bug does in fact fix the problem (at least, I couldn't repro with the backout) on master. I'm attaching the backout patch I used, generated by git revert with some fixup. It would probably be better to fix it in-situ than back this out though.

From talking to David this sounds like something Vivien could help with. Reassigning.

I can access the JS Bin demo, nor see the video on my laptop. But I've been able to reproduce a few different issues with multiple touch events on the dialer keypad or on the call log list. This patch should fix the issues I've seen while staying very simple until this code is converted to C++ in bug 976605. Asking the review to botond as IIRC fabrice is on PTO and botond has spend quite some time on this file in the last weeks :)

Vivien: Looks like this is R+, are you going to be landing this? This is blocking some Camera bugs for 1.4.

Landed on inbound: https://hg.mozilla.org/integration/b2g-inbound/rev/c4909da3d711

The issue still reproduces on 1.4 and master build Active state stuck with multiple on-screen touches 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140411000202 Gaia: 6c50349f41d40ba175ea0fc0c2c2cbd739ba7170 Gecko: 28b419f0e857 Version: 30.0a2 Firmware Version: v1.2-device.cfg 1.5 Environmental Variables: Device: Buri 1.5 Master BuildID: 20140411040203 Gaia: 1368d716072adf308e1b435ac828f97545a045f1 Gecko: d8c1b10c3a3d Version: 31.0a1 Firmware Version: v1.2-device.cfg

Using which test case? The JS Bin demo test case?

Something weird I noticed, I can't seem to reproduce it in the JS Bin anymore, but in the Camera settings menu, it reproduces almost 100% of the time with latest build.

I should note too that the settings menu in Camera is simply using `:active` in the same way that the JS Bin demo is. The only difference I can think of is that the Camera settings menu is not using <button> elements.

Re-opening - Here's a YouTube video showing the settings menu button getting "stuck" in the `:active` state 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

Bug 976605 is overhauling the way :active is handled with APZ on. It should land shortly; I suggest we retest after it lands.

Can you file a followup for this, given that this patch already landed?

Opened bug 997235 as a followup.