982320 - [B2G][Calendar]Tapping Month or Week view tab intermittently opens Add New Event screen when using Stylus rather than a person's finger

Status: RESOLVED DUPLICATE of bug 985218

(Core :: DOM: Events, defect)

Description

[Montoya Clemmons (MClemmons)]

Initially, user taps Calendar App and either Week or Day view to exit the default Month view. In either Week or Day view, when user taps Month or Week at the bottom of the device screen using a stylus, the Add New Event page inadvertently and intermittently opens. This is problematic as some users may be uncomfortable, unwilling or incapable of using their fingers all the time on a mobile device. Furthermore, on the attached video, you can fast forward to various points (specifically the 56 second mark) and see successive instances where the Month tab is highlighted when selected with the stylus yet the Add New Event screen opens.

Prerequisites:
Have a tool such as a stylus with durable rubber tip that allows user input on mobile device.

Repro Steps:
1) Updated Buri to BuildID: 20140310080111
2) Tap Calendar App and tap either Day or Week at bottom of device
3) Tap either Month or Week at bottom of device

Actual:
Intermittently, the Add New Event screen displays

Expected:
Either Month or Week view displays all the time

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140310080111
Gaia: 8c9191df3c107df4073f3ca63816a1d36c51af5d
Gecko: 923f1411f42f
Version: 30.0a1
Base image: v1.2-device.cfg

Repro frequency: 25/100 – 25%
Link to failed test case: https://moztrap.mozilla.org/manage/case/3590/
See attached: video clip http://youtu.be/aA-rUdvuIU4
Other information: Stylus used during this reported test http://www.amazon.com/Targus-Stylus-Generation-iPhone-AMM01US/dp/B003ZSHKIY

Comment 1

[Montoya Clemmons (MClemmons)]

This issue does not reproduce on 1.3 Buri. Following the STR from Comment 0 and the selected tab view displays as expected each time after attempting 100 taps total of the three options. The same stylus used during testing in Comment 0 was used during testing for 1.3 Buri. 

Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140310004001
Gaia: 78c30d7ed6f6e30337d6c05453b867f5e97e42bc
Gecko: 00f249d54bda
Version: 28.0
Base image: v1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

That's bizarre. I'm guessing this is a gecko bug. A window will confirm this.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Hey Vivien?  there was some way you were getting where the touch events were hitting in one of your builds.  Would it be possible to have that happen in 1.4 as well?  This might help with this bug.

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #3)
> Hey Vivien?  there was some way you were getting where the touch events were
> hitting in one of your builds.  Would it be possible to have that happen in
> 1.4 as well?  This might help with this bug.

That's bizarre.

mclemmons can you reproduce with APZC disabled ? I wonder if you are clicking outside the display port and then if we hit bug 973105 or something similar.

Comment 5

[Montoya Clemmons (MClemmons)]

(In reply to Vivien Nicolas (:vingtetun) (:21) from comment #4)
> (In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from
> comment #3)
> > Hey Vivien?  there was some way you were getting where the touch events were
> > hitting in one of your builds.  Would it be possible to have that happen in
> > 1.4 as well?  This might help with this bug.
> 
> That's bizarre.
> 
> mclemmons can you reproduce with APZC disabled ? I wonder if you are
> clicking outside the display port and then if we hit bug 973105 or something
> similar.

I am able to reproduce the issue in Comment 0 with APZC disabled. The repro rate was nearly equally intermittent 2/10 (20%) following the same STR from Comment 0. 

Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140314040202
Gaia: ea9e23abea5933656555d849b922c8da7530c90b
Gecko: fe40387eba1a
Version: 30.0a1

Comment 6

[Miller Medeiros [:millermedeiros]]

I did some tests and it's really weird.. I was not able to reproduce it as often as the video unless I pressed it "hard", but every single time that it did happen the click event clientY was always smaller than 433 (usually between 408 and 422), and current view as the Day View, which would explain why the add event screen was showing up.

I added the following code to the calendar app to debug the click events:

```
  window.addEventListener('click', function(e) {
    dump(
      '\n[click] target: ' + tag(e.target) + ' | clientX: ' + e.clientX +
      ' | clientY: ' + e.clientY + ' | layerX: ' + e.layerX +
      ' | layerY: ' + e.layerY
    );
  });

  function tag(el) {
    var name = el.tagName.toLowerCase();
    var id = el.id? '#'+ el.id : '';
    var className = el.className ? '.' + el.className.split(/\s+/g).join('.') : '';
    return '<'+ name + id + className + '>';
  }
```

it's weird because the click is definitely happening on a area that should report clientY above 425..

any regression window?

Comment 7

[Jason Smith [:jsmith]]

Switching to QA Wanted - does this reproduce on 1.4 with tiling disabled?

Comment 8

[Miller Medeiros [:millermedeiros]]

I did some investigation and I couldn't figure out why this happens.. for me it doesn't look like a calendar bug. The click event is reporting that click happened at wrong `clientY` (value is 30-40px smaller than expected); `event.target` points to element that is at the reported `clientY` - meaning that on the JS side all information tells us that user clicked an `.hour` element and not the "month" tab.

Need help from other teams to identify the cause.

Comment 9

[Jason Smith [:jsmith]]

comment 8 potentially reads off as a DOM bug.

Andrew - What do you think?

Comment 10

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #9)
> comment 8 potentially reads off as a DOM bug.
> 
> Andrew - What do you think?

Oh and - if you can find out if bug 985218 is a dupe of this bug, then that would be helpful as well. I think it is, but I'd prefer if a dev can confirm this.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Could it be that we used to flush layout (or scroll position or some such) more often, so the click went to the expected place, but we have optimized out some flushes and the layout isn't quite what is expected when click is dispatched. 

Anyhow, regression range is needed here.
(The regression can be in gaia or in gecko)

Comment 12

[Jason Smith [:jsmith]]

If this truly is a dupe, then this shouldn't be reproducing on the latest build right now, as the dupe's regressing patch was backed out.

QA wanted to see if this still reproduces on the latest 1.4.

Comment 13

[Brogan Zumwalt [Inactive]]

Unable to reproduce on latest 1.4 in 60+ tries using same model of stylus used in comment 0.

Environmental Variables:
Device: Buri v1.4 Mozilla RIL
BuildID: 20140321000202
Gaia: b09bf796d82ca7aa00d141a0cb705ee9cabfab47
Gecko: 81bfa88dada6
Version: 30.0a2
Firmware Version: v1.2-device.cfg