QA/Firefox3.5/ViewSource Testplan

« QA/Firefox3.1/TestPlan

Feature View Source Test Plan

Overview

 Provide an abstract of the feature and the test strategy.  
 Are there particular challenges with testing this feature?

The View Source feature displays the source markup for an HTML page as text rather than rendered markup. The text is displayed with syntax-based coloring, but is otherwise identical to the text retrieved by the browser from the server or filesystem. A new feature, "linkification" has been added for Firefox 3.1. Linkification treats the values of HREF and SRC attributes as URLs. So for example, imagine the following HTML:

 <a href="http://www.example.com/about.html">About</a>.

The text fragment http://www.example.com/about.html would be displayed as a hyperlink, linking to the URL view-source:http://www.example.com/about.html. Clicking on the link would replace the current source page with the source for the "about.html" page.

Test Strategy

 List major areas of test coverage
 List areas that will NOT be covered (by developer, third party, etc.)
 Describe how testcases will be created (litmus, mochitests, reftests, gristmill, etc..)

Overview of Test Strategy

View Source functionality will be broken down into two major components:

1. Existing (pre 3.1) view source functionality
2. URL linkification (new in 3.1)

Due to time constraints and resource limitation, this document will only attempt a cursory level of testing for existing view source functionality, with the understanding that this error will be fleshed out later.

Since the linkification feature is new and is likely to contain bugs, most of the test effort will be focused on it for 3.1.

Existing pre-3.1 features

There are three ways to open the view source window

1. View >> Page Source from the main menu.
2. View Page Source from the content area context menu.
3. Ctrl-U/Cmd-U

There is also a way to view source in a regular browser window/tab

Enter a view-source:url in the address bar (directly, by bookmark, or by clicking a link which has a view-source:url as its HREF). Note that functionality specific to the View Source window won't be available in this case, e.g. line wrapping. This is simply because the source is displayed in a regular browser window in this case rather than the View Source window.

Basic Functionality

1. It should be possible to select text in the view source text.
2. It should be possible to copy the selected text.
3. Find and Find Again should work.

Fidelity: Ensure that view-source does not corrupt the source

The text displayed by view-source should exactly match the source returned by the server or retrieved from the filesystem. It's possible for errors in the formatting code to cause characters to be omitted, for example. This is particularly important because subtle errors in the displayed source text may be quite hard to detect, but could still cause users considerable difficulty.

The plan is to assemble a small, but reasonably representative, set of HTML source files as a test suite. A mochitest or a series of mochitests will be written to automatically open view-source windows (possibly as IFRAMES) and extract (using document.body.textContent) the raw unformatted text. The mochitests will then compare the extracted text content with the actual source text retrieved directly from the file system.

Ultimately the suite of test HTML files will be greatly expanded to ensure good coverage. It may make sense to include XML files as well (including SVG files).

There should be an emphasis on view-source fidelity because it is very amenable to automated testing, and because it's extremely important.

Is the page source being retrieved from the cache?

View Source is designed to retrieve the source for a page from the browser cache whenever possible. This is because a server may return different data on two different requests, perhaps substantially so. Generally, when the user chooses to view the source of a particular page, they want to see the original source used to render the page they're looking at, not whatever source the server returns from another request.

The easiest way to test this logic is with an HTML form that posts back to its own URL. If the original form page and the page returned by the post look very different, then it's easy to test. Submit the form, wait for the response, and then view source to verify that view source shows the HTML for the response, not the original form. See bug Bug 469302.

Linkification of HREF and SRC URLs in Firefox 3.1

A two pronged approach will be used for testing the linkification feature: Automated testing (using Mochitests) wherever possible, and manual testing elsewhere. Since view source is heavily used by web developers and linkification has been a much requested extension, we can reasonably expect good test coverage from beta users.

Mochitests

The basic linkification functionality should be amenable to automated testing with Mochitests. The proposed approach is to embed view-source pages into Mochitest pages using IFRAME elements. Once a view-source URL has loaded into an IFRAME, the test code in the Mochitest page can examine its DOM looking for anchor elements -- currently the only way an anchor element can end up in the DOM of a view-source page is through the linkification feature.

By using a carefully crafted HTML page as the target of the view-source URL in the IFRAME it should be possible to test most of the basic aspects of linkification, starting with "Does linkification work at all", and moving to some of the thornier cases like entity expansion. Most of the test cases described in the section URL types below should be amenable to this sort of testing.

Manual Testing

Some aspects of the linkification feature will most likely need to be tested manually, at least in the near term. In particular history navigation -- i.e. <Back> and <Forward> will be easier to test manually. See the table in the Navigation through history section below.

URL types

Entities in URLS

When building view-source URLs from raw URLs, any entities in the URL should be expanded. For example, the HTML fragment

 <a href ="http://www.example.com/cgi/foo.cgi?a=foo&b=bar">foo, bar</a>

should produce the view-source URL (string representation after entity expansion)

 view-source:http://www.example.com/foo.cgi?a=foo&b=bar

Another way to think of this is that the "&" in the source URL should not get encoded twice, resulting in an invalid URL after getting decoded once.

URL schemes

Linkification is primarily useful for http and file URLs. However, as currently implemented, the linkification code doesn't take the URL scheme into account -- it simply slaps a view-source: in front of the URL. This works fine for "http" and "file" URLs that link to HTML files. The behavior needs to be tested for other URL schemes just to make sure the action that occurs when clicking the link seems sensible. For example view-source:mailto URLs seem to work the same way as plain "mailto" URLs, which is about all you can do with them. Smarter handling of the various URL schemes should probably be considered for the future.

1. http URLs
2. file URLs
3. mailto URLs
4. view-source URLs (e.g. view-source:view-source)
5. other URL schemes (gopher?!)

Absolute URLs, Relative URLs, and URL Fragments

URLs using the "view-source:" scheme only work when the source URL is absolute. Therefore the linkification code converts URLs extracted from HREF and SRC attributes to absolute URLs before building view-source URLs for them. Linkification uses as the base URL either the URL to the containing page, or the URL specified by a BASE tag in the containing page, as appropriate.

1. Absolute URLs, e.g. http://example.com/about.html.
2. Absolute URLs with fragments, e.g. http://example.com/about.html#item2.
3. Relative URLs, e.g. about.html.
4. Relative URLs with fragments, e.g. about.html#item2.
5. Relative URLs with fragments only, e.g. #item2.
6. Relative URLs with BASE elements

File types

Ideally the URLs generated by linkification would themselves be view-source URLs only when the referenced resource is to a file containing text markup which will be rendered by the browser (generally HTML, but could be various kinds of XML, including SVG). Other types of resources would just be represented using normal URLs. Unfortunately, we can't reliably determine file type from looking at the source URL -- we really need to know the MIME type returned by the server.

The strategy currently used by the linkification code is to simply turn every URL into a view-source URL, and let things fall as they may. For text formats like CSS and JavaScript, the text is rendered the same whether the file is read from the raw URL or the view-source version of the raw URL. Unfortunately, images are not displayed the same. If an image file is retrieved through a view-source URL, the bytes that make up the image will be displayed as if they were text (this is a bug and should be fixed). The current proposal is to make the code that handles view-source URLs smarter and have it fall back to non-view-source behavior for MIME types that are not known to be text types.

1. HTML (text/html, application/xhtml+xml, etc.)
2. JavaScript (text/javascript, etc.)
3. CSS (text/css, etc.)
4. XML (text/xml, etc.)
5. SVG (image/svg+xml, etc.)
6. Images (image/gif, image/png, image/jpeg, etc.)
7. Other MIME types

Navigation through the history: <Back> and <Forward>

Linkification now permits multiple pages to be viewed in a view source window. Consequently, history has been enabled and the <Back> and <Forward> operations are now supported.

In the table below, the last three columns assume that the view source window has been opened, a link in the page has been followed, and then a link in the second page has been followed. Consequently, there are three pages in the history for the window. In this scheme, "2/3" (for example), means that the second of the three pages in history is the one currently being displayed.

In the table, the context menu rows assume the localization language is English. The labels and keys (i.e. "B" and "F") will change with the language.

position in history ==>	1/1	1/3	2/3	3/3
context >> Back	disabled	disabled	goto first page	goto second page
context >> Forward	disabled	goto second page	goto third page	goto disabled
context >> "B"	no effect	no effect	goto first page	goto second page
context >> "F"	no effect	goto second page	goto third page	no effect
ALT-LEFT (win/linux)	no effect	no effect	goto first page	goto second page
ALT-RIGHT (win/linux)	no effect	goto second page	goto third page	no effect
CMD-[ (mac)	no effect	no effect	goto first page	goto second page
CMD-] (mac)	no effect	goto second page	goto third page	no effect
BACKSPACE (win/linux)	no effect	no effect	goto first page	goto second page

Schedule Scoping

 Estimate amount of time it will take to complete feature
 (Consider nightly builds, security reviews, bugs turnaround time)

The basic view source feature has existed for over 10 years. The most recent addition is the linkification of URL attributes. It is the latter feature that is most in need of testing at this time.

The linkification feature is "complete" at this time, but exhibits a number of bugs, some of them fairly severe.

It's difficult to estimate how long it will take to fix bugs introduced by linkification. The plan is to focus on the most severe bugs first. Given the relative simplicity of the linkification feature as currently implemented, it should be possible to get it working well enough to ship in the 3.1 release.

References

 Include notes, links, specs, relevant bugs

• Bug 17612: Bug 17612 – view-source link-browsing
• Bug 15372: view-source: URLs need overhaul
• Bug 463176: NS_ERROR_FACTORY_NOT_REGISTERED from nsIDocShellHistory.useGlobalHistory opening view source
• Bug 464314: view-source link-browsing doesn't decode entities
• Bug 464339: Links to images and non-textish media should not have view-source: links
• Bug 464388: View Source linkification triggers "ASSERTION: Error: no token allocator"
• Bug 464727: Incorrect linkification of view-source if newline follows the linkinfied attribute.
• Bug 79518: tracking view source UI
• Bug 455888: Make View Source not suck (view source meta bug)
• Bug 464361: Add support for back and forward mouse buttons to View Source
• Bug 229995: view source doesn't need history or security
• Bug 60426: Allow users to choose between generated and source html in view-source
• Bug 464222: Relative links not linkified in "View Selection Source"

 Bug 79518: Bug 79518 – tracking view source UI

Bugs that describe how View Source works (or is supposed to work) now

• Bug 469302: Page source code after form submit shows initial form page instead of new page
• Bug 15364: Add line numbers to View Source
• Bug 17612: view-source link-browsing
• Bug 22022: no wrapping in view source
• Bug 39389: No context menus in "view source" window
• Bug 49721: [RFE] View Partial Source capability
• Bug 50877: Menu items don't work in View Source window
• Bug 55583: view-source should show original page source (use cached source)
• Bug 59489: Cannot print page source
• Bug 63026: Give me the menu in View Source back
• Bug 63137: [FIX]View Source converts tags to lower case
• Bug 71173: find only works once in view page source window
• Bug 77337: [FIX]view-source: does not allow viewing of many text files
• Bug 80598: View source window does not focus the content area when it's brought up
• Bug 85752: move viewsource search menuitems to edit and kill the search menu
• Bug 85908: Add reload to View Page Source Window
• Bug 99676: ctrl-e in viewsource causes composer to load highlighted source

Bugs that are feature requests or known bugs

• Bug 8589: make view source optionally open in text/plain helper app
• Bug 11520: Ability to view stylesheet source.
• Bug 28809: [RFE] View Source at Selection
• Bug 47139: Make page source tabbed, each tab representing a frame
• Bug 57722: view-source leaves out whitespace at end of document
• Bug 60426: Allow users to choose between generated and source html in view-source
• Bug 74862: Ability to save highlighted source in view-source
• Bug 76250: enable Page Info menu item in View Source
• Bug 78619: View-source: pages have a view source option if opened by hyperlink
• Bug 79339: stop spawning view-source: urls in a new window when we support view-source: recursion
• Bug 87787: need a stop button for view source
• Bug 169198: Add "Raw View" tab to View Source window
• Bug 202659: remove items from edit menu in view source

 Bug 455888: Bug 455888 – Make View Source not suck (view source meta bug)

• Bug 11520: Ability to view stylesheet source.
• Bug 17612: view-source link-browsing
• Bug 246620: Add line numbers to View Source for Firefox
• Bug 455945: View Source should "linkify" links in the source -- i.e. show them as clickable hyperlinks
• Bug 455948: The view source window should have a toolbar with toggle-line-wrap and goto-line buttons.