The Gecko BugAThon
Maintained by Gerv
(with thanks to Bernd Mielke)
Help save Gecko engineers from imminent doom!
What is the BugAThon? (A call for volunteers)
Without help, the number of bugs submitted in the core areas of Gecko (Mozilla's Web display engine), such as the DOM, CSS, Layout etc. would overwhelm the developers.
Do you care about Web standards? Do you hate working around browser bugs? Don't just stand there--with engineers bleeding by the side of the road, are you going to be the Pharisee or the Good Samaritan?
You can help, and you don't need to be a C++ programmer! Simplifying bug reports to the simplest possible test case doesn't take too long per bug, but when you've got this many bugs, it really adds up. And every hour Gecko engineers spend decomposing bug reports is an hour they can't spend on FIXING bugs. The more bugs that are simplified, the faster Gecko engineers can fix them, and the fewer bugs there'll be!
Writing a testcase is the best and most productive way to vote for a bug. Overworked engineers tend to focus on bug's with testcases. If a bug bothers you, why it does still not have a testcase?
Contents:
- What is a simplified test case, and how do I make one?
- More tips and tricks
- How to find open bugs needing test cases
- What do all those keywords mean? What keywords should I use?
- Tech Evangelism <layer>, <ilayer>, document.layers, document.all, and bad userAgent sniffing Evangelism!
- Frequently encountered "bugs"
- Add a BugAThon banner to your site!
What is a Simplified Test Case, and How Do I Make One?
A simplified test case means the simplest possible Web page that still reproduces the bug. If you remove any more characters from the file of the simplified test case, you no longer see the bug. To turn a web page that shows a bug into a simplified test case, you:
- Open a Bugzilla account and download the latest milestone build or, preferably, a recent nightly build of the Mozilla browser.
- To claim a bug, choose one of the open bugs from the search links below and, if you think it'll take you a while, comment that you are making a test case so that effort is not duplicated.
- Download the Web page that shows the bug to your local machine. Use the "Web Page, Complete"
option in the save dialog to download all linked files, including JavaScript (.js), CSS
(
.css
), frameset (.html
), and image files. - Verify that you are not wasting your time on a tech evangelism bug.
- Using a text editor (like Notepad on Windows, SimpleText on the Mac, or vi or emacs on UNIX),
start removing HTML markup, CSS rules, and lines of JavaScript from the page. Start by commenting
out parts of the page (using
<!-- -->
) that seem unrelated to the bug. Every few minutes, check the page to make sure it still reproduces the bug. Code not required to reproduce the bug can be safely removed.You'll do well if you use an editor supporting multiple levels of Undo, and better if you use an HTML-editing tool which supports preview to an external browser.
- When you've cut away as much HTML, CSS, and JavaScript as you can, and cutting away any more causes the bug to disappear, you're done. If possible try to replace the image links with links to images at www.mozilla.org.
- Attach the test case to the Bugzilla bug report. If the test case requires multiple files (and
can't be shrunk by e.g. putting JavaScript or CSS in the <head>), upload the ancillary files
and then change the main file to reference the URLs of the attachments. That way, the testcase can
be viewed merely by clicking the link in Bugzilla. Enter "testcase" into the
Keywords1 2 field so engineering knows the bug is ready to be crushed.
1 A standard Bugzilla account does not have sufficient permissions to add keywords. After you have created testcases for two bugs, mail Gerv with links to the two bugs, and I'll upgrade your permissions.
2 Note that [TESTCASE] and similar names in the Status Whiteboard have been deprecated; if you come across a bug with a test case which has this, but not the testcase keyword, please add the keyword.
More tips and tricks
The following describes steps you can take when reducing a test case:
- Generated content: some content may be generated dynamically by javascript
(
document.write()
). To view the generated code, select the content, right click (or press Shift+F10), and choose "view selection source" from the context menu. The generated source code will be selected in the view source window.Sometimes, Gecko may interpretate generated content source and the equivelent raw source code differently. To see if this is the case, comment out the content-generating javascript (with
/* */
) and insert the equivelent source code (obtained from the view source window). Test in the browser to see if there is any difference. - Table: To visualize table layout more clearly, put the following code in the
<head>
section to show cell borders:
-
<style type="text/css">
table { border-collapse: collapse; }
/* top-most tables will have red cell borders */
table td, table th { border: 1px solid red !important }
/* tables nested one level deep will have orange borders */
table table td, table table th { border: 1px solid orange !important }
/* tables nested two level deep will have green borders */
table table table td, table table table th { border: 1px solid #00cc33 !important }
/* tables nested three or more level deep will have blue borders */
table table table table td, table table table table th { border: 1px solid #3399ff !important }
</style>
If you want to see how images interact with tables, insert the following style rule into the previous
<style>
code:-
img { border: 1px solid purple; }
-
- Standards and Quirks modes: Gecko will display Web pages in either Standards Compliance
mode or Quirks mode, depending on the Web page document type. Press Ctrl+I the open the
Page Info dialog to see the rendering mode. If the page is rendered in Standards Compliance mode,
then replace the DocType definition at the very beginning of the source file with the following
line:
-
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN">
-
- Review frequently encountered "bugs" to make sure you do not get caught up with invalid bugs.
- Bookmarklets: Jesse Ruderman has written some bookmarklets (small bits of JavaScript) which are very useful for reducing testcases. (E.g. "ancestors", "show blocks", "view scripts", "view style sheets" and "edit styles".)
- Real-Time HTML Editor: There is also a real-time HTML editor, for building testcases from the ground up.
How to Find Open Bugs Needing Test Cases
These links lead to bugs with several priorities for each category:
- qawanted - developers screaming for your help
- high priority bugs
- unconfirmed bugs and
- the rest
Confirmed bugs have been verified as present by QA people or entered by bugzilla veterans, and are less likely to be dupes. Unconfirmed ones, on the other hand, are usually recently submitted and are bound to be of variable quality.
Working with UNCONFIRMED bugs involves overlap with the tasks on the QA confirmation page. Very often a good testcase is the only way to triage the bug correctly.
Bugs by Component:
The Tricky Ones For Plugin Paladins: The following plugins have their own special Bugzilla keywords: (realplayer and shockwave. Each of these bug lists also needs de-duping, and the remaining bugs reduced to a test case. By this, we aren't asking you to edit realplayer files or the like, but merely to remove as much surrounding HTML/CSS/JS etc. as possible.
What Do All Those Keywords Mean? What Keywords Should I Use?
For a complete, up-to-date list of keywords used in the Bugzilla keyword field, see keyword definitions for Bugzilla. Here's a brief summary of the keywords most relevant to the BugAThon.
Code | Meaning |
---|---|
4xp | Because of this bug, Mozilla is not currently backwardly-compatible with the behavior of Navigator 4.x. (The code stands for "4.x Parity.") |
compat | Not a bug, but something so commonly misused on the internet that we should provide a work-around for it. i.e., we do it right, but older browsers get it wrong. |
testcase | A volunteer has finished a test case for this bug. Putting testcase in the Keywords field removes the bug from the lists of bugs that need test cases. |
Tech Evangelism
Web page authors using <layer>, document.layers, document.all, or doing bad userAgent sniffing must be Evangelised!
There are pages on the web that do not display well or have JavaScript errors in Mozilla because they use
javascript and HTML features proprietary to Microsoft Internet Explorer or Netscape 4. Such features include
document.layers
, document.all
, and the <layer>
and
<ilayer>
HTML tags. Mozilla won't support these proprietary features (see
Mozilla Technology Evangelism for details).
If you are examining a bug report in Bugzilla and realize that it's caused by these issues, please follow the evangelism guidelines.
Frequently Encountered "Bugs"
The following lists some frequently claimed bugs:
- Extra spacing between images and table cell: if a Web page is rendered in Standard Compliance mode, then by default table cells will have the minimum height of the text line height (see bug 22274)
- Flash transparency does not work: Gecko supports plug-in transparency as Microsoft Internet Explorer does. However, Macromedia has not upgraded their Mozilla Flash plug-in to take advantage of this (see bug 93959)
- Image ALT does not show up as tooltip: see bug 25537 comment 153.
Add the BugAThon Banner Ad to Your Site!
Glenn Davis of ProjectCool.com has kindly given us this banner ad to help promote the BugAThon:
Please add the banner ad to your web pages! To add the banner ad to a web page:
- place the mouse cursor over the image, right-click the mouse button, and choose "Save Image As ..." from the popup context menu that is displayed;
- save the image as bugathon.gif in the same directory as your web page;
- and add the below HTML to your web page:
<div align="center"><a href="http://www.mozilla.org/newlayout/bugathon.html">
<img src="http://www.mozilla.org/newlayout/bugathon.gif" height="60" width="468"></a></div>