You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.
What is Networking QA?
Networking QA can be divided into several main areas:
Contributors should understand that the "Networking" component is only for certain "core" aspects of networking. Many bugs that look like networking problems may end up in other components.
Here is a list of the more commonly mentioned components, and what belongs in them:
|Browser: Networking||Necko issues that do not clearly belong in other "Browser" components related to networking. Includes URL schemes, URL parsing, DNS, Proxy, SOCKS, PAC.|
|Browser: Networking:File||file:/// URLs and various file I/O functions in Necko|
|Browser: Networking:FTP||ftp://URLs and FTP client behavior|
|Browser: Networking:HTTP||http://URLs and http client behavior|
|Browser: Networking: Cache||Caching of HTTP, FTP and DNS|
|Cookies||Closely related to HTTP|
|File Handling||In a nutshell, if you are not going to look at something (Layout), but save it to disk or a helper app.|
||If something typed in the Location bar fails,
but works when put into a link, it's not a Necko bug.
|Image Lib||Display, caching and management of graphical content|
|MailNews||Unless directly related to a component above, MailNews networking problems stay with the MailNews product|
|Installer||Installer is mostly a separate HTTP|FTP client, and networking problems stay with the Installer component.|
||Docshell is usually he layer that receives
networking errors and displays alerts
||"Back" and "Forward buttons"
For a more specific description, look at the official component
Components for Browser
Not all networking behavior is actually tested in this area, mainly due to the structure of the code and the relationship to Necko. For testing purposes, Necko should be considered the stuff that finds and gets info on the network. Figuring out *what* is asked for, and how it is handled is often something outside of Necko. For example, many "networking" features in the UI are actually XP Apps that use Necko. The general rule of thumb is HTTP and FTP are tested as part of Necko, everything else (mailnews, chatzilla, Netscape IM, installer) is handled by the module owner.
Who does Networking QA?
Update: Netscape (AOL) does not provide any more resources for QA.This component is completely in the hands of the contributor community now. Many individuals lend their time in the network related components. They are too many to name individually, but their help is always appreciated, and if you hang around the various components enough, you will find out who they are. Additionally, we would, at some point, like to get interested individuals to own specific areas of Networking (like Proxy, PAC, and URLs).
Networking standards bugs live in certain bugzilla components, but are logically subdivided into the following:
|Technology||Default QA contact||Specialists
|URLs (schemes, parsing, routing)||email@example.com
|Proxy (HTTP, SSL Proxy, FTP)||benc|
|HTTP (http:// | https://)
|Necko code + crashers||<open>
Needs a QA contact:
Gopher, SOCKS, PAC, IPv6, Finger
Who's components depend on Network QA?
browser-general, mailnews, installer, PSM, XP apps (Reload button, back & forward, offline-online, save and download file, view source.).
These components are not part of Necko engineering, and not directly
tested by Networking Standards QA.
We support the other QA groups in two ways:
Most exceptions are because the bug has been moved around during QA triage or engineering assignment, and the component or QA was not set correctly. Valid exceptions should have a note in the body of the record.
Who does release notes?
Historically, Networking QA has managed the drafting of release notes. More on this later.
Ben's current goals:
Clear Verification list (bugs marked Resolved/<anything>)
Develop test server capabilities - start with a list of hardware and software.
Write and publish test cases for my components.
streamlined code verification protocol.
Verify resolved/fixed -> Relnotes
Comprehensive bug audit/test case re-write.
Generic test plans
Functional test plans
Isolate URL code entry points
Non-necko functional test plans
Omni-spoofing DNS/routing reverse proxy buster