QA/Talkback/FAQ

From MozillaWiki
< QA‎ | Talkback(Redirected from QA:Talkback:FAQ)
Jump to: navigation, search

« Back to QA/Talkback

Maintained by Samuel Sidler

  1. What does it mean when I see the following error when submitting a crash incident: "The Agent is unable to connect to the server. Please check your Proxy Server settings or try again later."?
    This error message is misleading. It does not always indicate a proxy related problem or mean that your incident has not been submitted to the Talkback Server.
    We do know that a lot of people with slower connections (dialup, isdn) sometimes have timing issues and do not get a response from the Talkback server saying that their crash was successfully processed and stored. If you open up talkback.exe, find an Incident ID, and look it up with FastFind, chances are you will find your crash.
    For more info, see Bug 210251, Comment 70.
  2. How do I disable Talkback? (not recommended)
    If you are having problems submitting crash incidents and continue to see the error discussed above, you can disable Talkback:
    Start the Add-ons Manager (Tools => Add-ons Manager) select Talkback, and click "Disable".
  3. What data is sent with my crash incident?
    There are a number of things that are included in the crash incident that is submitted to us. For more info, see the Old QFA page on mozilla.org (a bit outdated, but it shows you how to check what data will be sent with the Talkback Client after you crash). Currently, there isn't any other way to get a complete list of what's sent until Talkback appears. Then, clicking the "Details" button will show you everything you might want to know (and allow you to uncheck items you don't want to send).
  4. What additional information should I specify when submitting a crash incident?
    Aside from the data collected automatically by Talkback, the crash dialog allows you to specify your email address, a URL, and comments about your crash. It is important that you provide us with as much useful information as you can to improve our ability to debug the issue. This includes the website you were visiting, any plugins or extensions you think might be related to the crash, what you were doing, etc. If you have been able to crash consistently, exact steps to reproduce the crash would be ideal!
    • NOTE: If you submit your email address, it will be kept private (only Mozilla employees will be able to see that data). Personal information like IP and email addresses will not show up in public Talkback reports or query results.
    • TIP: If you want to easily look up your own incidents, you can always add a unique string that you will remember in the URL or Comments field and then query for it with QuickSearch
      • e.g. in the Comments field I might enter something like: "Crash submitting a from at http://someurl [jpcrash20060130]" - that way, I could go search for "jpcrash" and get all of my incidents in one easy query.)

  5. Will you be looking at feedback from old builds? E.g. will you be looking at crash data from Firefox 2.0.0.7 in a month? Or is it only crashes in recent builds that are interesting?
    This is a great question and the answer will explain exactly why we need more help from the community. To get a better understanding of which builds need to be looked at, you first need to understand which development branches exist and which product/project releases come off of them:
    • Mozilla Trunk (FirefoxTrunk, ThunderbirdTrunk, MozillaTrunk [SeaMonkey])
    • Mozilla 1.8.0 Branch (Firefox15, Thunderbird15, SeaMonkey10)
    • Mozilla 1.8 Branch (Firefox2, Thunderbird2, SeaMonkey11)
    Looking at that list, I'll try to explain what type of crash analysis needs to be done for each:
    1. The Trunk branches are the latest bleeding edge builds with a lot of new features and changes being checked in. These builds are great to look at to find regressions quickly and get them fixed right away. However, most of these reports aren't as useful since the introduction of Breakpad. To get a better feel for trunk crashes, please use the Breakpad (Socorro) site.
    2. The Mozilla 1.8.0 branch is where Firefox 1.5.0.x and Thunderbird 1.5.0.x are released. Since Firefox 1.5.0.x is no longer supported, we tend to only look at crash data for Thunderbird between minor releases. Most of crashes that happen on this branch and occur in Thunderbird are also fixed on the Mozilla 1.8 branch if they occur there.
    3. The Mozilla 1.8 branch is the current stable branch, building both Firefox 2 and Thunderbird 2. This is where the bulk of our time is spent; analyzing topcrashes that occur on this branch. For more information on analyzing topcrashes, please see the relevant article.
    As you can see, there are plenty of things to keep track of... and since it's not possible for one person to keep up with everything on their own, we can use all the help we can get. A few people already do a lot of crash analysis on their own, but we can always use more eyes! If you have any questions, feel free to hop into the #qa channel in IRC and ping "ss". Also, take some time to query for crash bugs in Bugzilla by looking for the "crash" and "topcrash" keywords...that should give you a good idea of what is out there now.

  6. If there is a backlog of incidents waiting to be processed on http://talkback-public.mozilla.org/talkback/fastfind.jsp, can I look at the crash info for my recent incidents on my computer?
    Unfortunately, the data is not in a human-readable format on your local machine so there is no easy way to view it. You have to wait until the Talkback Server has processed your incident before looking it up by Incident ID or finding it in any query results.
  7. I'd love to know if there is any trend analysis and/or reporting that I could do to help the coders identify the most common and/or problematic issues. Can I access the data and do analysis from my web browser?
    Yes! There are already a number of reports for the various development branches and official releases that already organize the crash data and sort it by total number of incidents. This not only helps us focus our work on the most critical crashes, but allows you to easily browse the data to do whatever type of crash analysis you want. There are also query tools for you to create your own reports on the fly. All of this can be found at http://talkback-public.mozilla.org/talkback/fastfind.jsp.
  8. Does Talkback send what extensions/plugins you have installed? If not, should we list them in the comments?
    No, Talkback does no automatically send us information about your particular extensions or plugins. Therefore, it is a great idea to include that type of information in the comments field when you're submitting a crash report (but usually only if you believe your crash is related or due to some extension or plugin). The comment field is for you to enter as much data as you want about the crash, so feel free to include anything and everything you care to tell us about. :-)
  9. Why doesn't Talkback start when my build crashes using Mac OS X 10.4 on an Intel-based Mac?
    Talkback for Mac was built as a PPC-only application. That means it will only run on on machines using PPC processors. This will be fixed in Firefox 3 with the introduction of Breakpad, an open source alternative to Talkback.
  10. As a developer for Mozilla's SVG code I'd like to learn how to narrow crash results to crashes occuring on SVG content.
    There are a number of ways to narrow down your query results to find specific types of crashes. For this case we'll look at SVG, but the same approach can be taken for any part of the code, feature, or component. Using the QuickSearch query tool at http://talkback-public.mozilla.org/talkback/fastfind.jsp, you can try the following:
    • Search by a keyword in the Comments field (e.g. "svg"). This might not give you exactly what you want, but should provide a good number of crashes from people that were looking at SVG content...and from those results, you will be able to find some good URLs and comments to help look into SVG crashes.
    • Search by a function in the code in the Stack Signature field (e.g. "nsSVGGradientFrame::GetNextGradient", "NPSVG3.dll"). You can even search for substrings (just make sure to select the proper pull down item for where in the complete string to search, like "Contains", "Begins With", etc.).
    • Search by a website in the URL field (e.g. "http://www.w3.org/Graphics/SVG/"). This probably isn't the best option, unless you already know of a website that people have been crashing on consistently...but it can allow you to see what types of crashes are happening at certain popular websites.