- 1 Status
- 2 Overview
- 3 Design Impact
- 3.1 Security and Privacy
- 3.2 Exported APIs
- 3.3 Web Compatibility
- 3.4 Performance
- 3.5 Reliability
- 3.6 l10n and a11y
- 3.7 Installation, Upgrade/Downgrade/Sidegrade, and platform requirements
- 3.8 configuration
- 3.9 Relationships to other projects - are there related projects in the community?
- 3.10 Documentation
- Feature tracking bug
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
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.
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.
- 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
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.
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.
Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
Does it interoperate with a web service? How will it do so?
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?
Does it change any existing interfaces?
Does the feature had any impact on Web compatibility?
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)?
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)?
Does it require changes to the installer?
Does it impact updates?
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.
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?
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.
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?
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?