- Renames CloseTabsSettingsFragment.kt to TabsSettingsFragment.kt
- Renames close_tabs_preferences.xml to tabs_preferences.xml
- Adds preference options for the switching between the Grid and List tab views
The difficulty in mocking StrictMode.resetAfter is concerning.
I'm starting to second-guess whether or not making strict mode manager a class
was a good idea.
I believe this was a premature optimization: it's unclear that it would
actually improve performance and yet we had to add several weird
workarounds to make it work that broke encapsulation. It's also
possible it would be worse for the APK size because of excessive
inlining.
Before it used to output the violations all one one line. Now it looks
like:
```
MozillaStrictModeSuppression:
'import mozilla.components.support.ktx.android.os.resetAfter' at
(17,1) in /StrictModeManager.kt
Please use `components.strictMode.resetAfter` instead because it has
performance improvements and additional code to monitor for performance
regressions.
MozillaStrictModeSuppression:
'setThreadPolicy(threadPolicy.build())' at (56,24) in
/StrictModeManager.kt
Please use `components.strictMode.resetAfter` instead because it has
performance improvements and additional code to monitor for performance
regressions.
MozillaStrictModeSuppression:
'setVmPolicy(builder.build())' at (71,24) in /StrictModeManager.kt
NOT YET IMPLEMENTED: please consult the perf team about
implementing`StrictModeManager.resetAfter`: we want to understand the
performance implications of suppressing setVmPolicy before allowing it.
```
This is more correct, faster, and results in less copy-paste duplication
than the current behavior:
homeScreen { }.dismissOnboarding()
Which opens settings to dismiss onboarding.
set save button state by calling invalidateOptionsMenu, causing onPrepareOptionsMenu to be called which will enable/disable the save button depending on if changes have been made or not