Status

Feature tracking bug

• bug 411490

Has a design review been completed?

The feature is simple in nature and the bulk of the code was reviewed by Mano

When do you anticipate the feature landing

The feature has already landed and is present in beta 3

Overview

Describe the goals and objectives of the feature here.

The goal is to provide an easy way for testers and users to get at the list of submitted breakpad crash reports. Before this feature the only way to do this involved outside extensions or finding the correct directory on disk and listing the files there.

Use Cases

Describe the primary use cases for the feature here.

• A developer that crashes will want to view the crash report, they can visit about:crashes to see the reports in date order
• A user is experiencing crashes, a supporter can direct them to copy some id's from about:crashes to try to see if there is a bug filed on the crashes and potentially provide a workaround.

Requirements

• Provide simple access to a list of submitted crash reports
• Sort the crash reports in date order to simplify finding the relevant report
• Provide a means to remove old crash reports

Schedule

The feature was checked in about a week before the beta 3 freeze with a couple of follow up check ins to improve the UI in case of problems and enable the feature in other applications.

UI Design Documentation

The UI is simply based on the ftp file listing display already in the browser.

Design Impact

Security and Privacy

What security issues do you address in your project?

The possibility of script injection into the page is avoided by using DOM methods to create the page content and the urls for the anchors are always prepended by the crash reports server preference which is checked to ensure that it begins with http: or https:

Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

If the preference pointing to the crash report server is missing then the feature will display an error to that effect. The same is true if the preference points to anything other than a http or https url.

Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

The about:crashes page runs with chrome privileges. It is not marked as safe for untrusted content to link to. This should mean that websites cannot cause the user to see the about:crashes page the only way to visit it would be through UI actions.

In order to add the ID's to the page DOM methods are used. This means that even if an attacker were to somehow get a file into the crash reports directory they wouldn't be able to use it to insert a script element or similar into the page since the DOM methods should escape any of that correctly.

The server report url is checked to ensure it is either http or https, this means that an attacker could not inject a javascript link into the page by using a javascript: url as the preference.

Exported APIs

Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

None

Does it interoperate with a web service? How will it do so?

No

Explain the significant file formats, names, syntax, and semantics.

The feature reads a list of files from the crash reports directory and displays the id of the reports. The ID is made by taking the file name and dropping the leading "bp-" and trailing ".txt". The contents of the files are not read.

Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

N/A

Does it change any existing interfaces?

No

Web Compatibility

Does the feature had any impact on Web compatibility?

No

Performance

How will the project contribute (positively or negatively) to "perceived performance"?

The feature makes life easier for users seeking support when they are already experiencing problems. Anything we can do to help these users out makes things easier for them.

What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?

The feature is not on any startup or other critical path so the only real performance goal was for the reports list to display in a reasonable time.

Will it require large files/databases (for example, browsing history)?

No

Reliability

What failure modes or decision points are presented to the user?

If the report server preference is not set or invalid then this is displayed.

Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

There are no files written to by the feature.

l10n and a11y

are any strings being changed or added?

Yes some strings were added, all in http://mxr.mozilla.org/seamonkey/source/toolkit/locales/en-US/crashreporter/

are all UI elements available through accessibility technologies?

This is untested however the UI is a standards compliant webpage and so should be accessible.

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

Does it equally support all Tier-1 platforms?

Yes the feature was tested on all tier 1 platforms

Does is have a hardware requirement (or increase minimum requirements)?

No

Does it require changes to the installer?

No

Does it impact updates?

No

list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

No behaviour is needed on upgrade/downgrade since the feature holds no local state.

configuration

Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

There is one preference used to point to the crash reporter for the application. This is generally set as a default in the application preferences and should never be changes. If a user chose to change this in about:config then they would end up with links in about:crashes that no longer point to the crash report server.

Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No, the feature is enabled/disabled by the already present MOZ_CRASHREPORTER define

What ranges for the tunable are appropriate? How are they determined?

N/A

What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

The crash report server preference may need changing if the crash reports server moves.

Relationships to other projects - are there related projects in the community?

If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

The feature is applicable to any Mozilla based project that uses the breakpad crash reporter. The feature can be enabled on any Mozilla based project by simply setting the crash report server preference and providing a means to load about:crashes in a browser.

Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?

No

Documentation

Do built-in Help pages need modified?

The support page http://kb.mozillazine.org/Breakpad has already been updated explaining how to use the feature.

Documentation for developer.mozilla.org?

N/A