- Feature View Source Test Plan
- 1 Overview
- 2 Test Strategy
- 3 Existing (pre 3.1) view source functionality
- 4 URL linkification (new in 3.1)
- 5 View >> Page Source from the main menu.
- 6 View Page Source from the content area context menu.
- 7 Ctrl-U/Cmd-U
- 8 It should be possible to select text in the view source text.
- 9 It should be possible to copy the selected text.
- 10 Find and Find Again should work.
- 11 http URLs
- 12 file URLs
- 13 mailto URLs
- 14 view-source URLs (e.g. view-source:view-source)
- 15 other URL schemes (gopher?!)
- 16 Absolute URLs, e.g. http://example.com/about.html.
- 17 Absolute URLs with fragments, e.g. http://example.com/about.html#item2.
- 18 Relative URLs, e.g. about.html.
- 19 Relative URLs with fragments, e.g. about.html#item2.
- 20 Relative URLs with fragments only, e.g. #item2.
- 21 Relative URLs with BASE elements
- 22 HTML (text/html, application/xhtml+xml, etc.)
- 24 CSS (text/css, etc.)
- 25 XML (text/xml, etc.)
- 26 SVG (image/svg+xml, etc.)
- 27 Images (image/gif, image/png, image/jpeg, etc.)
- 28 Other MIME types
- 29 Schedule Scoping
- 30 References
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:
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.
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:
Existing (pre 3.1) view source functionality
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
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.
It should be possible to select text in the view source text.
It should be possible to copy the selected text.
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.
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.
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.
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)
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.
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.
view-source URLs (e.g. view-source:view-source)
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.
Absolute URLs, e.g. http://example.com/about.html.
Absolute URLs with fragments, e.g. http://example.com/about.html#item2.
Relative URLs, e.g. about.html.
Relative URLs with fragments, e.g. about.html#item2.
Relative URLs with fragments only, e.g. #item2.
Relative URLs with BASE elements
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.
HTML (text/html, application/xhtml+xml, etc.)
CSS (text/css, etc.)
XML (text/xml, etc.)
SVG (image/svg+xml, etc.)
Images (image/gif, image/png, image/jpeg, etc.)
Other MIME types
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
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.
Include notes, links, specs, relevant bugs
Bugs that describe how View Source works (or is supposed to work) now
Bugs that are feature requests or known bugs