GNOME Bugzilla – Bug 713006
Better error reporting
Last modified: 2017-12-15 14:21:58 UTC
---- Reported by jim@yorba.org 2012-05-18 15:01:00 -0700 ---- Original Redmine bug id: 5281 Original URL: http://redmine.yorba.org/issues/5281 Searchable id: yorba-bug-5281 Original author: Jim Nelson Original description: Errors currently go unreported to the user. In general the only way to know if an operation has failed is by looking at the debug log or noticing that nothing changed in the UI (message still marked as read, archive button does nothing, etc.) We should consider how we can report errors to the user in an unobtrusive way (i.e. no modal dialogs). Related issues: related to geary - 5304: Alert the user when their SMTP connection has failed (Open) related to geary - 6032: Account creation/add/edit dialogs reappear without explan... (Fixed) related to geary - 6200: Messages with certain attachments sit in the outbox forever (Open) related to geary - 7481: report SMTP send errors to the user (Fixed) duplicated by geary - 7284: No error message when email account is mis- configured (Duplicate) duplicated by geary - 7347: IMAP communication failed (Duplicate) duplicated by geary - 6516: Forwarded messages and replies sometimes stay in the outb... (Duplicate) ---- Additional Comments From geary-maint@gnome.bugs 2013-08-09 16:52:00 -0700 ---- ### History #### #1 Updated by Jim Nelson about 1 year ago * **Subject** changed from _Better error reporting_ to _[string] Better error reporting_ #### #2 Updated by Jim Nelson about 1 year ago * **Subject** changed from _[string] Better error reporting_ to _Better error reporting_ * **Target version** deleted (<strike>_0.2_</strike>) On second thought, this is too large a change for 0.2. We'll need to get this in the next release. #### #3 Updated by Jim Nelson about 1 year ago * **Target version** set to _0.3.0_ #### #4 Updated by Jim Nelson 10 months ago * **Tracker** changed from _Bug_ to _Feature_ #### #5 Updated by Jim Nelson 9 months ago * **Target version** changed from _0.3.0_ to _0.4.0_ * **Keywords** set to _string-change_ #### #6 Updated by Eric Gregory 8 months ago See this ticket for DNS issues that are silently failing: https://bugs.launchpad.net/geary/+bug/1157735 #### #7 Updated by Jim Nelson 6 months ago See #6963 for the mechanism describing how background processing is reported. We envision a similar mechanism for error reporting, except rather than State and percentage being signalled, it would be the Error object and translated text ready for human consumption. #### #8 Updated by Jim Nelson 3 months ago * **Target version** changed from _0.4.0_ to _0.5.0_ --- Bug imported by chaz@yorba.org 2013-11-21 20:18 UTC --- This bug was previously known as _bug_ 5281 at http://redmine.yorba.org/show_bug.cgi?id=5281 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
There's at least two things to consider here: 1. Transient notification when the error actually occurs (Failed to connect to server, protocol errors, failure to send message, etc.) 2. Indicating when there is an ongoing error or warning condition (e.g. offline, not connected, host name lookup failure, etc.) The former is probably going to be best handled using in-app notifications, so I'm going to make this depend on Bug 774442. The later needs some design work - online/offline state is a global state, per-account connection problem, errors sending messages, etc need per-account indicators.
Per Bug 774442, we might want to consider using an InfoBar for reporting persistent/fatal errors, so we have a place to put a GUI for accessing technical details like error messages, and so on. Per Bug 746924, another thing to consider reporting as additional technical details is any server response message.
I've been doing some thinking about the design of this the wiki: https://wiki.gnome.org/Apps/Geary/Design/Notifications - feedback welcome. There's a WIP branch based on that, implementing using InfoBars per the the design document going up at wip/713006-better-error-reporting, which should be landing on master after it gets a bit more testing locally.
*** Bug 712992 has been marked as a duplicate of this bug. ***
*** Bug 779718 has been marked as a duplicate of this bug. ***
Hey Piotr, related to your note in https://bugzilla.gnome.org/show_bug.cgi?id=774442#c4, are you happy with the approach taken here on the WIP branch, eg: https://git.gnome.org/browse/geary/tree/src/client/components/main-window-info-bar.vala?h=wip/713006-better-error-reporting#n54 I.e. doing: > _("some %s string").printf("good"); Rather than: > _("some %s string".printf("bad")) I checked the "make pot_file" generated POT file and the strings are showing up, but I'm not sure if that was the source of the problem, rather than something else.
It’s not that the strings weren’t extracted to .pot/.po files, it’s that they were displayed always in English in the UI. I don’t know much about coding. You should ask Michael Catanzaro, who diagnosed the problem. Who knows, maybe I’m wrong and these two cases are different. :)
This has been fixed on master by commit a36b2c5. Geary now will use an InfoBar to display important error conditions to the user, provide a means to retry the issue, and access technical details if available (including a stack trace). There's still plenty of situations where Geary silently ignores errors, but we can address them as we find them since we now have the infrastructure to do so.
(In reply to Piotr Drąg from comment #7) > It’s not that the strings weren’t extracted to .pot/.po files, it’s that > they were displayed always in English in the UI. I don’t know much about > coding. You should ask Michael Catanzaro, who diagnosed the problem. Who > knows, maybe I’m wrong and these two cases are different. :) Hey, you know your way around a code base pretty well at least! :) Now that this has landed on master, I'll test out the translations as they roll in and fix see if this approach works, and rework to use Michael's approach if not.
Err, actually this landed in commit d1d8d64. Whoops.
(In reply to Michael Gratton from comment #9) > Hey, you know your way around a code base pretty well at least! :) Now that > this has landed on master, I'll test out the translations as they roll in > and fix see if this approach works, and rework to use Michael's approach if > not. So have you had a chance to test it? Czech, Indonesian and Polish translations are complete.
(In reply to Piotr Drąg from comment #11) > > So have you had a chance to test it? Czech, Indonesian and Polish > translations are complete. Yeah, seems to work fine!
Thanks, I’m glad to hear that.