The bug #1238979 improves the situation with updates to the results model, but it doesn't solve the problem of poor connection.
For this to be possible I think we will need cooperation from scopes, because only the scopes know if all the data they serve comes from network and if old results should be preserved if network is not available. Scopes currently receive connectivity status with every search, so they can use push_surfacing_results_from_cache() method of the SearchReply to push the old results again without any extra work. We could make it even easier for scopes to handle this by enhancing CompletionDetails in scopes API with a new status such as InternetRequied (displays appropriate banner to warn the user) or InternetRequiredAndKeepTheResults (banner + keep old results on the screen) - but are easy to implement in the shell, but the bulk of work would be to update scopes to use it.
The bug #1238979 improves the situation with updates to the results model, but it doesn't solve the problem of poor connection.
For this to be possible I think we will need cooperation from scopes, because only the scopes know if all the data they serve comes from network and if old results should be preserved if network is not available. Scopes currently receive connectivity status with every search, so they can use push_surfacing_ results_ from_cache( ) method of the SearchReply to push the old results again without any extra work. We could make it even easier for scopes to handle this by enhancing CompletionDetails in scopes API with a new status such as InternetRequied (displays appropriate banner to warn the user) or InternetRequire dAndKeepTheResu lts (banner + keep old results on the screen) - but are easy to implement in the shell, but the bulk of work would be to update scopes to use it.