1155251 - [E-Mail] Signature window can open twice on double tap

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Oliver Nelson [:oliverthor]]

Attachment: logcat_20150416_0828.txt

Description:
When the user is editing their email account information, they will observe a field for 'Signature' that will navigate the user to a new window to where they may edit their signature. If the user double taps this field, they may open the window twice, enforcing the user to drop back out twice.


Repro Steps:
1) Update a Flame to 20150416010206
2) Open the E-Mail app
3) Sign into email account
4) Navigate to email settings
5) Observe the 'Signature' field
6) Double tap the 'Signature' field
7) Observe windows opening

Actual:
Two 'Signature' windows open; user has to back out of both. Behavior becomes unexpected from saving these fields

Expected:
Only one 'Signature' window opens


Environmental Variables:
--------------------------------------------------

Device: Flame 3.0
Build ID: 20150416010206
Gaia: 629097847567e51095a454e7e63186a6e2ac0307
Gecko: a35163f83d22
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Device: Flame 2.2
BuildID: 20150416002504
Gaia: 8e24d8b7f5e7c74c3004b22710dda0dac3e04ead
Gecko: 41388836b5c6
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
--------------------------------------------------
Issue DOES NOT REPRO on 2.1 for flame devices
Results: When tapping 'Signature' for new window, phone navigates quicker and with less lazy load time; can't stack taps and create duplicate windows

Device: Flame 2.1
BuildID: 20150416001203
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: c54aa1be51d6
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
--------------------------------------------------


Repro frequency: 6/10
See attached: 
video- https://youtu.be/60N3uggd87g
logcat

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

I looked at this briefly because of my interest in the click eater.  The logs, oddly, seem to show the pushCard logs being rather spaced out, like over 500ms or 600ms apart, but I couldn't establish a direct correspondence with the video.  In general I'd just wonder if the click eater is being defeated by the custom element stuff that is on v2.2 but not on v2.1.

Comment 2

[James Burke [:jrburke]]

I am having trouble reproducing with a latest master flash. I have not been able to reproduce at all yet.

My current theory is that APZ or something related somehow registers two taps, but waits to send the final tap until after the animation to the next card finishes. Or if the scroll area where the signature button is registered as scrolling and taps are ignored until it stops scrolling/the APZ scroll threshold, then sends the second tap, but against the settings card, not the signature card.

If that is the case, then we might be able to reproduce with other buttons, on systems that can reproduce.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Maybe we could add a log to Cards._onMaybeIntercept like this to trunk to help out?

console.log('click! target:', event.target, 'originalTarget:',
            (event.target === event.originalTarget ? 'same' : event.originalTarget),
            'eating?', this._eatingEventsUntilNextCard,
            'when?', Date.now() - event.timeStamp, 'ms ago');

The rationale would be:
- Ideally if the event got backlogged somewhere, that comes across in the "ms ago" thing.
- We can see if we did suppress redundant clicks / if the logic is working
- We can see what is getting clicked on, in case the problem involves something really unexpected
- I include the originalTarget stuff because custom elements.  Maybe we don't need it.

Note that I'm assuming that the only time the user would be frenetically tapping on the email app is while typing, and that wouldn't be intercepted by this mechanism since the keyboard app is its own app and frame.

Comment 4

[Peter Bylenga [:PBylenga]]

hesitant to call this a regression given comment 0 findings.

NI on QA component owner to take a look.

Comment 5

[Teri Wen [:twen]]

Reproduced on v2.1 and v2.2. Can't seem to reproduce it on master. 

Also not observed on v2.2 nexus 5.

Gaia-Rev        d50b8a3919a7b4d8d289f150d3b9bed704ebafa9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/5ebf32030512
Build-ID        20150416162504
Version         37.0
Device-Name     hammerhead
FW-Release      5.1
FW-Incremental  eng.cltbld.20150416.201018
FW-Date         Thu Apr 16 20:10:32 EDT 2015
Bootloader      HHZ12d

Set tracking flag for now.

Comment 6

[BMO Automation]

Firefox OS is not being worked on