AutomatedProblemReportsNotification

Differences between revisions 2 and 3
⇤ ← Revision 2 as of 2006-07-29 07:14:24 →
Size: 2774
Editor: c-68-33-112-13
Comment: Delete unrelated stuff added from my copy-paste job; add some refinement.
← Revision 3 as of 2006-07-29 15:47:25 → ⇥
Size: 2892
Editor: c-68-33-112-13
Comment: Clarify what this spec does; add more use cases
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
This is largely just for eye candy; however, when a user is automatically reporting problems, the more security sensitive data may need review. Alerting the user to crashes and delivery of reports is a good thing if you want to draw attention here; but at the same time we will probably annoy the user by going into "panic mode" and throwing a dialog in his face. As per AutomatedProblemReports, "Depending on the environment, we can potentially provide different crash handler frontends. As a first small implementation for Gnome, a daemon in the desktop will watch /var/crash/ with inotify; if it detects a crash report it can read, it creates a notification which points to the file and asks to file a bug."

AutomatedProblemReports does not go into specific detail on the crash handler front-ends. This spec attempts to.
Line 17: Line 20:
 * Alice is automatically reporting problems; we do not need to go into "panic mode" and throw a dialog in her face every time a crash occurs.
 * Bob experiences a Firefox crash, and clicks the "crash icon" in his Notification Area to review the security sensitive parts of the report and send them after he's sure they do not contain passwords.
Line 20: Line 24:
The scope of this spec includes things reported by AutomatedProblemReports. The scope of this spec includes all things reported by AutomatedProblemReports.
Line 27: Line 31:
   * Crashes are "new" when no other crashes appear to be from the same cause for a certain time period (i.e. a month).
   * For the time being, let's limit the crashes we identify as the same:
     * Stack Smashes that call `__stack_chk_fail()` from the same function
     * Heap corruptions and double-`free()` detections that had `malloc()` or `free()` called from the same application function.
Line 52: Line 52:
Kernel Oopses and failed package installation needs to be addressed.

Summary

This spec describes giving visual feedback through the Notification Area when AutomatedProblemReports are triggered and non-sensitive data about crashes is being automatically sent.

Rationale

As per AutomatedProblemReports, "Depending on the environment, we can potentially provide different crash handler frontends. As a first small implementation for Gnome, a daemon in the desktop will watch /var/crash/ with inotify; if it detects a crash report it can read, it creates a notification which points to the file and asks to file a bug."

AutomatedProblemReports does not go into specific detail on the crash handler front-ends. This spec attempts to.

Use cases

  • Rhythmbox spontaneously crashes, and the end user notices a "crash icon" in his Notification Area.
  • Alice is automatically reporting problems; we do not need to go into "panic mode" and throw a dialog in her face every time a crash occurs.
  • Bob experiences a Firefox crash, and clicks the "crash icon" in his Notification Area to review the security sensitive parts of the report and send them after he's sure they do not contain passwords.

Scope

The scope of this spec includes all things reported by AutomatedProblemReports.

Design

A tool similar to update-notifier should exist to give visual feedback of AutomatedProblemReports through the notification area. This tool should display different icons depending on the current situation, for example:

  • No icon when nothing is waiting.

  • Information icon when new crashes have been sent but extra information (stack dumps) needs review.

  • A crash icon for when a crash was detected

    • Should look rather harmless, perhaps a spiky ball
    • If automatic reports aren't being sent, we may want to pulse this every few seconds as opposed to entering "panic mode" and slapping the user with a dialog box

  • Add a communication indicator when a report is being sent (automatically or user-triggered)

    • Should overlay crash icon

Implementation

We will need icons to display.

We will need this code either written from scratch or added to whatever user interface is created for AutomatedProblemReports.

Code

Code will be needed in the areas described in Implementation.

We will need AutomaticProblemReports working first.

Data preservation and migration

No issues exist.

Unresolved issues

Kernel Oopses and failed package installation needs to be addressed.

BoF agenda and discussion

Comments

CategorySpec

AutomatedProblemReportsNotification (last edited 2008-08-06 16:39:16 by localhost)