mozilla-b2g/gaia — pull request #20828 by jrburke (2014-06-20 22:19:30+00:00)
Title: Bug 1025727 - [email/cronysync] Failsafe abort/window.close after failed cronsync(s)

This pull request introduces a failsafe close mechanism based on the cronsync mechanism.

The bulk of the work is done in wake_locks, since we ideally need the wake locks still active if some other UI data actions is occurring, like a mid-stream draft save or message send, and the wake lock timeout gives us a strong signal that something has gone wrong.

For the wake_lock timeout, it now uses a new function, closeIfNoDataOps, to decide if the app should be closed. If there are no in-process UI data actions, then it will proceed with closing the app if the app is currently in a hidden state. It was previously confirmed that the system will free any locks automatically for closed apps.

If the app is visible when the wake lock timeout occurs, then the locks are just cleared, and we wait for the next sync pass or regular other-app use to OOM email.

compose triggers uiDataOperationStart and uiDataOperationStop events to indicate in-process UI data actions: either saving a draft or sending a message.

If there are in-process UI data actions, there is a 5 second grace period to finish before the failsafe kills the app. This is done because one of those UI data actions could be contributing to the reason sync has gone bad, and it is more important to just shut down and reset. The odds of reaching that state should be very low, the UI data actions will likely complete in time, but we need an ultimate failsafe pathway just in case.

This will likely need to be revisited with background send. If it is an email send with a large attachment, that could also be a problem, but only if email is in the background when that happens. The most likely cause of getting into this state though, when sync fails so that this pathway is considered is if the network connections have gotten into a weird state, so sending is not likely to complete anyway.

Tests were performed by putting in an early return in sync.js at the top of its api.oncronsyncstop function, at line 108. This made it appear that syncing did not complete. Then the following things were tried, using a 60 second test interval:

* regular background sync with email closed. Saw the "force closing app" message and confirmed email was not running after that.
* regular background sync with email, but then tapping email icon so it is visible. Saw "app still visible" and email kept running.
* Changed compose to not emit the uiDataOperationStop event, then waited for a sync to start, opened a compose and saved draft, then went back to home screen. Saw the "waiting on email data operations" message with "saveDraft" mentioned, then 5 seconds later the app was closed.