MozillaWiki

QA/Firefox3.5/ViewSource Testplan: Difference between revisions

Page Discussion

QA/Firefox3.5/ViewSource Testplan (view source)

Revision as of 03:41, 24 March 2009

7,935 bytes added ,  24 March 2009
m
QA/Firefox3.1/ViewSource Testplan moved to QA/Firefox3.5/ViewSource Testplan
 
(31 intermediate revisions by one other user not shown)
Line 1: Line 1:
<small>[[QA/Firefox3.1/TestPlan|&laquo; QA/Firefox3.1/TestPlan]]</small>
<small>[[QA/Firefox3.1/TestPlan|&laquo; QA/Firefox3.1/TestPlan]]</small>


;Feature <abc> Test Plan
;Feature View Source Test Plan


= Overview =
= Overview =
Line 8: Line 8:
   Are there particular challenges with testing this feature?
   Are there particular challenges with testing this feature?


The View Source feature displays the source HTML of a page as the original text, not as rendered markup.  The related View Selection Source command displays just the source for the selected range on the page.
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:


View Page Source may be invoked several ways.
  <a href="http:''//''www.example.com/about.html">About</a>.
1. Select '''View >> Page Source''' from the main menu.
2. Select '''View Page Source''' from the page context menu.
3. Press '''Ctrl-U/Cmd-U''' on the keyboard.


View Selection Source may only be invoked from the context menu when some content on the page is currently selected.
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 =
= Test Strategy =
Line 23: Line 20:
   Describe how testcases will be created (litmus, mochitests, reftests, gristmill, etc..)
   Describe how testcases will be created (litmus, mochitests, reftests, gristmill, etc..)


== test strategy: overview ==
== Overview of Test Strategy ==


View Source functionality will be broken down into two major components:
View Source functionality will be broken down into two major components:
Line 33: Line 30:
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.
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.


== test strategy: existing pre-3.1 features ==
== Existing pre-3.1 features ==


=== There are three ways to open the view source window ===
==== There are three ways to open the view source window ====


# View >> Page Source from the main menu.
# View >> Page Source from the main menu.
Line 41: Line 38:
# Ctrl-U/Cmd-U
# Ctrl-U/Cmd-U


=== There is also a way to view source in a regular browser window/tab ===
==== 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).
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 ===
==== Basic Functionality ====


# It should be possible to select text in the view source text.
# It should be possible to select text in the view source text.
Line 51: Line 48:
# Find and Find Again should work.
# Find and Find Again should work.


=== Fidelity: ensure that view-source does not corrupt the source ===
==== 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 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.
Line 60: Line 57:


There should be an emphasis on view-source fidelity because it is very amenable to automated testing, and because it's extremely important.
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 [http://bugzilla.mozilla.org/show_bug.cgi?id=469302 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&amp;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.
# http URLs
# file URLs
# mailto URLs
# 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
===== 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.
# HTML (text/html, application/xhtml+xml, etc.)
# JavaScript (text/javascript, 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
==== 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.
{| border="1"
|-
! 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 =
= Schedule Scoping =
Line 68: Line 205:
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 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.  Some of these "bugs" are arguably missing sub-features rather than bugs, but at this point the distinction is probably meaningless.
The linkification feature is "complete" at this time, but exhibits a number of bugs, some of them fairly severe.


The linkification feature is new for Firefox 3.1.  The amount of time to "complete" the feature has been arbitrarily declared as the amount of time left on 3.1.  Bugs/missing sub-features will be triaged and the most important ones will be fixed first.  It should be possible to fix all the serious bugs and, hopefully, implement the most serious missing subfeatures in the time remaining.  Bugs or missing sub-features which are "annoying" rather than serious can wait until Firefox 3.2 to be addressed if necessary.
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 =
= References =
Line 97: Line 234:
=== Bugs that describe how View Source works (or is supposed to work) now ===
=== Bugs that describe how View Source works (or is supposed to work) now ===


* [http://bugzilla.mozilla.org/show_bug.cgi?id=469302 Bug 469302]: Page source code after form submit shows initial form page instead of new page
* [http://bugzilla.mozilla.org/show_bug.cgi?id=15364 Bug 15364]: Add line numbers to View Source
* [http://bugzilla.mozilla.org/show_bug.cgi?id=15364 Bug 15364]: Add line numbers to View Source
* [http://bugzilla.mozilla.org/show_bug.cgi?id=17612 Bug 17612]: view-source link-browsing
* [http://bugzilla.mozilla.org/show_bug.cgi?id=17612 Bug 17612]: view-source link-browsing
Samuelsidler
1,457

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/116996...135703"