Description: When the user taps the sound or replay icon during the gameplay screen, the pause menu is displayed. Repro Steps: 1) Update a Open_C to BuildID: 20140513000208. 2) Download "Cut the rope" from the Marketplace. 3) Launch the application. 4) Select "Play". 5) Select "Cardboard Box" 6) Select any level available. 7) Tap the sound icon or the replay icon next to "MENU". 8) Observe the pause menu is displayed. Actual: The pause menu is displayed, after being shown in the up-side-down vertical view for a second. Expected: The sound setting turns on/off when the user selects the sound button, or the game is reloaded on the current level when the user selects the replay button. 1.4F Environmental Variables: Device: Open_C 1.4F MOZ BuildID: 20140513000208 Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93 Gecko: c140bcd02b9b Version: 30.0 Firmware Version: P821A10V1.0.0B06_LOG_DL Repro frequency: 90% Link to failed test case: N/A See attached: Video, logcat

This issue DOES occur in Buri 1.4. 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140513000208 Gaia: b40103dec34a147c9018a1af76eb21c3184f2f93 Gecko: c140bcd02b9b Version: 30.0 Firmware Version: v1.2-device.cfg This issue DOES occur in Flame 1.4. 1.4 Environmental Variables: Device: Flame 1.4 MOZ BuildID: 20140512000204 Gaia: 17fb44880e95bc7ae363a609d811bf5a9a067b5b Gecko: ec24f847e7c0 Version: 30.0 Firmware Version: v10F

This issues does NOT occur in Open_C 1.3 1.3 Environmental Variables: Device: Open_C 1.3 MOZ BuildID: 20140505052400 Gaia: Unknown Git commit; build date shown here. Gecko: Version: 28.0 Firmware Version: P821A10V1.0.0B06_LOG_DL

Can we get a clarification of what behavior is exactly seen on 1.3?

The sound button and the replay button responded correctly on 1.3, without bringing the pause menu. When the user selects the sound button, the button changes to on or off. When the user selects the replay button, the game restarts on the same level. The buttons responded correctly regardless the speed of the tapping by the user.

Maybe a DOM bug?

Issue occurs on the earliest available tinderbox build for Open C 1.4. Result: The pause menu is displayed, after being shown in the up-side-down vertical view for a second. Environmental Variables: Device: Open C v1.4 Tinderbox BuildID: 20140424123005 Gaia: fc95009476fac9ce205a59b237d146ca7f6f42e7 Gecko: 37237034e45c Version: 30.0a2 Firmware Version: P821A10V1.0.0B06_LOG_DL

Try doing the window on a Buri device.

Does this happen on master?

Switching to qawanted to check 2.0.

This issue DOES repro on Open_C 2.0

We do not have b2b-inbound builds available for this period of time. Therefore, the regression window was found using Tinderbox builds. Last Working Environmental Variables: Device: Buri BuildID: 20140203150906 Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20 Gecko: 23555d9a4a17 Version: 30.0a1 Firmware Version: v1.2-device.cfg First Broken Environmental Variables: Device: Buri BuildID: 20140203151506 Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20 Gecko: c150845d077d Version: 30.0a1 Firmware Version: v1.2-device.cfg Gaia is the same on both builds. This indicates that it is a Gecko issue. Gecko Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=23555d9a4a17&tochange=c150845d077d

The window here doesn't make any sense. There's only one gecko bug in that range & that bug doesn't seem relevant to the root cause here.

I have worked with Erik and we determined that the two builds above do not actually have the same Gaia. Mozilla Central Hamachi Regression window: Last Working Environmental Variables: Device: Buri BuildID: 20140203150906 Gaia: 53483b08ac780d19c085874006763bb1ef45c83d Gecko: 23555d9a4a17 Version: 30.0a1 First Broken Environmental Variables: Device: Buri BuildID: 20140203151506 Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20 Gecko: c150845d077d Version: 30.0a1 Last Working gaia / First Broken gekko - Issue does not occur Gaia: 53483b08ac780d19c085874006763bb1ef45c83d Gecko: c150845d077d First Broken gaia / Last Working gekko - Issue occurs - This indicates it is a Gaia issue Gaia: 75e9691f02b9d18585c18a5434beeff39ee7ea20 Gecko: 23555d9a4a17 Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/53483b08ac780d19c085874006763bb1ef45c83d...75e9691f02b9d18585c18a5434beeff39ee7ea20 B2g inbound builds are not available as far back as necessary to get a more precise window.

So there's a bunch of touch handling changes in the system app in this regression range. Maybe the root cause is due to one of those changes? Tim - What do you think?

Judging by the area touched, I suspect this is a regression of bug 958584.

Can we do a regression range check based on comment 16?

Can't do that. The range in comment 14 is as deep as we can go on tinderbox.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #16) > Judging by the area touched, I suspect this is a regression of bug 958584. Yes probably, having a look.

Nice one, the event forwarding works perfectly, but since we don't prevent default the system-app-only mouse events the cut the rope frame get's blurred and decides to show the menu. Patch incoming :)

So that's basically a workaround for bug 1005815 ?

Comment on attachment 8425447 [details] Gaia PR Didn't realized this is a 1.4+. So let's land the workaround in 1.4 and we should really move forward on 1.5 with the real fix. r+ with a comment referencing the real issue.

(In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, needinfo? please) from comment #23) > Comment on attachment 8425447 [details] > Gaia PR > > Didn't realized this is a 1.4+. So let's land the workaround in 1.4 and we > should really move forward on 1.5 with the real fix. > > r+ with a comment referencing the real issue. Note - I'd rather that we would land the workaround on all branches & file a followup for making the real fix. The reason for this is that landing an upper branch workaround only causes us to carry over blockers across releases. We also have to remember to land the workaround again if the real fix doesn't make it into 2.0 in time.

(In reply to Jason Smith [:jsmith] from comment #24) > (In reply to Vivien Nicolas (:vingtetun) (:21) (NOT reading bugmails, > needinfo? please) from comment #23) > > Comment on attachment 8425447 [details] > > Gaia PR > > > > Didn't realized this is a 1.4+. So let's land the workaround in 1.4 and we > > should really move forward on 1.5 with the real fix. > > > > r+ with a comment referencing the real issue. > > Note - I'd rather that we would land the workaround on all branches & file a > followup for making the real fix. The reason for this is that landing an > upper branch workaround only causes us to carry over blockers across > releases. We also have to remember to land the workaround again if the real > fix doesn't make it into 2.0 in time. Makes sense, this patch landed on master. The real fix is tracked in a separate bug and mentioned in the code so everything should be ok.

v1.4: https://github.com/mozilla-b2g/gaia/commit/5cf90f2bc058c8a8f9353ee7381f546791d27405

Verified as fixed on 1.4 in the following devices: 1.4F Environmental Variables: Device: Flame 1.4F BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: v10F-3 1.4 Environmental Variables: Device: Open_C 1.4 BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: P821A10V1.0.0B06_LOG_DL 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140522000200 Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34 Gecko: c3c0c57daef8 Version: 30.0 Firmware Version: v1.2-device.cfg

Verified as fixed on master 2.0 Environmental Variables: Device: Open_C 2.0 BuildID: 20140522040230 Gaia: ef66efa34ed8a559c8998bde688fae88eb943a7a Gecko: b40296602083 Version: 32.0a1 Firmware Version: P821A10V1.0.0B06_LOG_DL