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.

Skip to main content

About Networking QA

What is Networking QA?

Networking QA can be divided into several main areas:

How are networking problems tracked by mozilla.org?

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.
URL Bar
 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
 Docshell is usually he layer that receives networking errors and displays alerts
History
 "Back" and "Forward buttons"

For a more specific description, look at the official component descriptions:
    Components for Browser

Outdated special "networking rules" (left for historical purposes, for now)

  1. Networking has a "component-based" default owner. (For a while, there was an email address that was a placeholder, so you could watch only the new bugs). Most other components use the engineer as the default owner, which does not work as well, because if you watch the engineer, you get all their bug mail, even if you are interested in only one thing. See bug 120481 for more detailed discussion. The original proposal is available here.

  2. Networking has "sub-components", because it is so big and diverse

    Conn (Connectivity)
    DNS
    Proxy
    SOCKS
    PAC
    IPv6
    URL
    Finger
    Gopher
    about:
    res: | resource:
    data:
    text2HTML

    Bugs relating to these specific areas should have the sub-component at the beginning of the summary. (If you see bugs that do not conform to this naming system, consider updating the summary. Eventually, we might have sub-component level mail tracking as well, by using the "QA owner" field (for example, pacqa, socksqa, etc.)

  3. Contributor (non-Netscape) QA and Verification.
    I'll provide a longer reason later, but if you find a bug that has been fixed by the owner or marked "Works for me (WFM)" by the reporter, if the bug has a milestone of "Futured" or "--", you can mark it VERIFIED (if you actually verify it as working).

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) benc andreas.otte@debitel.net
DNS benc
Proxy (HTTP, SSL Proxy, FTP) benc
HTTP (http:// | https://)
  • Cookies
  • Cache
 tever
File (file://) benc
FTP (ftp://) benc
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:

  1. Networking problems in these components are often reported in (or moved to) "Networking" as part of problem analysis.
    2. Networking QA will triage incoming bugs and attempt to route them to the correct component.

  2. Networking problems in these components often utilize basic networking,  DNS or Proxy servers.
    3. Networking QA will provide technically support (test systems and problem analysis) so these networking problems can be resolved quickly.
Why are bugs QA assigned to the way they are?
Engineering assignment of bugs is strongly typed to the component that needs to be fixed. Generally, an open bug (anything which is not Status=VERIFIED) should be owned by the QA contact of the current component.

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.

Mozilla projects:
streamlined code verification protocol.
 
Priorities:
Verify resolved/fixed -> Relnotes
Comprehensive bug audit/test case re-write.

To Do:
Generic test plans
Functional test plans
Isolate URL code entry points
Non-necko functional test plans
Proxy futures
Omni-spoofing DNS/routing reverse proxy buster