893047 - [email] do not eat tap events on startup

Status: RESOLVED FIXED

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

Description

[James Burke [:jrburke]]

With the HTML cache in bug 886446, as the real cards are inserted after the cache, there can be an up to 5 second delay for tap events to trigger actions because those insertions are treated as possible card transitions, and normally taps should not work during those times.

However, for these startup insertions, they are "immediate", and they do not have to block the taps. Furthermore, the event blocking is long since it waits for the folder_list card to be inserted. However, that only occurs after the message_list card has been inserted with data from the database. Since the folder_list card is not visible during startup, it could be possible just to skip the work for it up front, and only insert once it is supposed to be shown.

Initial thought on the fix:

1) Do not set Cards._eatingEventsUntilNextCard to true during this startup sequence. That could mean just not doing it for "immediate" card transitions, but may just be scoped to startup cards only.

2) Consider not inserting the folder card up front. This would reduce overall work during startup. If this change is too large, then it may be broken out as a separate ticket.

Comment 1

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

Attachment: Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/11024

Pointer to Github pull-request

Comment 2

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

Comment on attachment 776979 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/11024

I was having trouble using the e-mail app in Firefox nightly where you do the thing where you build a profile with DEBUG=1 and then run that profile in nightly.  I thought this had to do with the magic logic that converts clicks to touches, but it was this bug.  Some race that happens on desktop but not on the phone was permanently rendering clicks eaten for all time.  Owing to some current sleepiness, I'm not able to muster the brainpower to explain what this race was, but I do have sufficient brainpower to justify this set of changes, at least I think :)

The patch here basically just stops us from eating events if the pushCard showMethod is 'none' for both the dynamic load case and the actual push case.

I think this patch might be enough to entirely mark this bug fixed, but it's conceivable there's something else going on.  Like I said, sleepy.

Comment 3

[James Burke [:jrburke]]

Comment on attachment 776979 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/11024

r+ from me. Let's land this and mark this bug fixed. 

The work I started to do for this, including removing the folder_picker from initial startup, led me down the path of just starting on 892069. That is a much bigger change, and this issue prevents desktop from working, so let's land this fix to close out this bug, and I will do the folder_picker changes in 892069, since they were going to happen anyway with that ticket.

Looking more into the causes of the issue that is fixed by your patch: _showCard is never called for showMethod 'none', and _showCard turns clicks backs on. So it is likely that if the last card inserted is the folder_picker, then clicks will never be enabled, without this patch.

So this just looks like a hole that has been there for a while, but probably easier to trip up now with the folder_picker card insertion delayed longer now with the latest code.

Comment 4

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

landed in gaia/master:
https://github.com/mozilla-b2g/gaia/pull/11024
https://github.com/mozilla-b2g/gaia/commit/4504dfae143a3f45d03e71a9836bc7d08757ec56