GNOME Bugzilla – Bug 714217
Offline mode
Last modified: 2021-07-05 13:26:49 UTC
---- Reported by jim@yorba.org 2011-06-22 10:02:00 -0700 ---- Original Redmine bug id: 3767 Original URL: http://redmine.yorba.org/issues/3767 Searchable id: yorba-bug-3767 Original author: Jim Nelson Original description: Geary should be able to detect when the network is unavailable and go into an offline mode where the user can continue operations on the email stored locally. Related issues: related to geary - 5180: Connection does not close when network is unavailable (Fixed) related to geary - 5410: New message not in conversation list & subsequent message... (Invalid) related to geary - 5801: allow entering offline mode even when machine is online (Open) related to geary - 5358: Crash when archiving and no connection available (Open) related to geary - 5565: crash in geary_imap_client_session_manager_on_disconnected (Fixed) related to geary - 6259: canceling SMTP password prompt exits geary (Open) related to geary - Feature #6344: allow the engine to delay making remote connections (Fixed) related to geary - 6975: Use default avatar when offline (Open) related to geary - 7235: Queue drafts locally when sending to server (Open) related to geary - 6651: Messages not loaded chronologically (Open) related to geary - 6776: 15s timeout is not enough for MoDem and pre-3G mobile con... (Open) related to geary - 7548: Cannot log in to second account after declining to log in... (Open) related to geary - Feature #7606: Add Button send/receive and time settings (Duplicate) ---- Additional Comments From geary-maint@gnome.bugs 2013-09-26 14:53:00 -0700 ---- ### History #### #1 Updated by Jim Nelson about 1 year ago * **Category** set to _engine_ * **Target version** set to _0.3.0_ #### #2 Updated by Jim Nelson 12 months ago This has been requested downstream: https://bugs.launchpad.net/geary/+bug/1081940 #### #3 Updated by Jim Nelson 10 months ago * **Target version** changed from _0.3.0_ to _0.4.0_ #### #4 Updated by Jim Nelson 8 months ago * **Target version** changed from _0.4.0_ to _0.5.0_ #### #5 Updated by Jim Nelson about 1 month ago Because we have no notion of a disabled account (one where the user has created it but has declined to enter a password), perhaps one way to approach Offline Mode is that an Account can be offline as well as the Engine. That means an Account can be forced offline by the Engine, or presumably set offline by the user. If Geary had similar semantics for offline mode with the Engine, that might be enough. (The Engine forcing itself offline would probably be due to network unavailability, not passwords, since the Engine layer doesn't deal with those.) If the Engine was offline, all Accounts would be offline. Engine offline mode overrides Account offline mode. Something like that. --- Bug imported by chaz@yorba.org 2013-11-21 20:25 UTC --- This bug was previously known as _bug_ 3767 at http://redmine.yorba.org/show_bug.cgi?id=3767 Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
*** Bug 737335 has been marked as a duplicate of this bug. ***
It looks promising to have a --offline switch to start a client for non-distracted reading (as Bug 714278 suggests), implemented also as a typical pause || sign in the toolbar. This could easily solve bug 714818 as well.
See https://tools.ietf.org/html/rfc4549 for some technical details about the best way to sync mailboxes when going online.
At the moment, operations performed offline on an Inbox will likely succeed after some of the work going into Bug 789924, and given that the client keeps Inboxes open for the lifetime of the application - ops will be queued in the replay queue and executed when connectivity has returned. This only true for other folders if the user keeps the folder selected until connectivity has returned so the client doesn't close it and causing its replay queue to be flushed. I was thinking that perhaps one way to handle this is to implement Bug 790308 and pause executing operations until connectivity has returned, but that would mean operations aren't reflected locally until going back online, and might also make it difficult to implement some of RFC 4549's recommendations. So maybe we want to avoid flushing the replay queue when folders are closed instead? This might give us the context needed to fully implement RFC 4549's recommendations, as well as making sure that ops are executed locally right away.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/geary/-/issues/ Thank you for your understanding and your help.