Bug 701092 originally implemented some functionality to detect successive crashes and then turn off session restore for the next start, however that functionality got lost when parts of the startup session restore code were moved to Java.
This patch re-implements this functionality within the Java UI. Unlike the previous implementation, we don't reset the crash counter in onPause(), because often enough onPause() will execute even after a crash. Instead, we check in onResume() whether our last foreground activity cycle crashed or not.
To avoid cross-process writes and reads to shared preferences, the crash reporter no longer sets the relevant flags in GeckoApp's shared prefs directly, but instead writes an empty CRASHED file to the Mozilla directory as a flag, which is then checked for by the main process during startup.
Alternative solutions considered were:
- Using Context.MODE_MULTI_PROCESS for accessing the shared prefs. Works, but forces the shared preferences to always be re-read from storage and is also deprecated from API 23 onwards.
- Using a ContentProvider for managing the cross-process shared prefs as suggested in Google's documentation. Seems somewhat over-engineered for this use case.
- Sending a broadcast from the crash reporter to signal the main process, so it can update the relevant shared prefs from the correct process. Doesn't work reliably immediately after crashing - sometimes the broadcast never arrives.
- Setting the crash flags directly in the crash handling functions in GeckoAppShell. Could work even when not building the crash reporter, however doesn't work easily for native crashes, because those are handled internally by Gecko without going through the Java crash handling code.
MozReview-Commit-ID: 6g7AmnJhoQk
--HG--
extra : transplant_source : %C2%F28%D9%8A8%08%C6%9F%A4%03%D7%EC%81F%B9%21%3A%E2x
The crash reporter runs in its own process but uses GeckoApp's shared prefs both to store its own settings and to signal to the main process that it has crashed, which can be somewhat problematic because each process might fail to notice settings changes made by the other process. As the simple solution of enabling Context.MODE_MULTI_PROCESS for accessing the shared prefs is now deprecated, we'll devise an alternative solution instead.
In Part 1 we move the settings that are used exclusively by the crash reporter into a separate shared prefs instance.
MozReview-Commit-ID: 1QWBAL2Xcn2
--HG--
extra : transplant_source : %C4%D2%C0%82%F3%19%E1%19%D9%82%11w%D3%D9%B3%DC%9Be%95%91
test_alarm_fires_with_when is failing intermittently and it looks like the function inside the setTimeout (which is designed to detect that the alarm did not fire as expected) is firing, even though the test is passing and the alarm did fire. I added a condition around it so it will only mark the test as failed if the alarm did not in fact fire.
I also did some clean up of the existing tests, including adding this type of logic to all tests that expect an alarm or alarms to have fired.
MozReview-Commit-ID: JlJQVMNn6wV
--HG--
extra : amend_source : f0a37030b717390a7ae8b87ef3aef68cc747c14d
Reasons for replacement:
* The old method was untested
* The Scanner class is supposedly slower than using Streams directly (which
the new methods do)
* If possible, it's generally better not to duplicate solutions - using the
Scanner works around the infrastructure this changeset series built (i.e. using
Streams).
In the edge cases, getFileContents:
* throws NoSuchElementException for empty files. The new behavior is to return
the empty string. Since getFileContents was always wrapped by `new JSONObject`
or similar, and we throw when the file is empty, the behavior should stay the
same.
* throws NoSuchFileException for missing files. This is the same as the
new behavior.
MozReview-Commit-ID: 6ESPss29emU
--HG--
extra : rebase_source : 24af07bddd585b857ebd8eb4eff4c7ac4898ba37
This method duplicates an existing method (readFileContents) which will later
be removed.
MozReview-Commit-ID: 2aVf74KvYyP
--HG--
extra : rebase_source : 3aa814f3e227fba4c5bab9434894aef6178da333
Javadoc in this commit references a method that is not yet added.
MozReview-Commit-ID: Hc0MSLYTQgD
--HG--
extra : rebase_source : bb30eb579fd8450a0b4698d38333b468f3b6e372
I would have separated these methods but version control fail.
MozReview-Commit-ID: 7og2iBKqHiH
--HG--
extra : rebase_source : 62db6247aedfc3683249f093a8d3688e6408ab17
