+2010-03-20 Maciej Stachowiak <mjs@apple.com>
+
+ Reviewed by Mark Rowe.
+
+ Fix a bunch of HTML5 validation errors on various pages.
+ https://bugs.webkit.org/show_bug.cgi?id=36409
+
+ * building/build.html:
+ * building/checkout.html:
+ * building/debug.html:
+ * building/run.html:
+ * building/tools.html:
+ * coding/coding-style.html:
+ * coding/contributing.html:
+ * coding/major-objects.html:
+ * css/main.css:
+ (.asciiart):
+ * demos/index.html:
+ * header.inc:
+ * projects/compat/index.html:
+ * projects/css/index.html:
+ * projects/documentation/index.html:
+ * projects/goals.html:
+ * projects/index.html:
+ * projects/mathml/index.html:
+ * quality/bugpriorities.html:
+ * quality/bugwriting.html:
+ * quality/crashlogs.html:
+ * quality/lifecycle.html:
+ * quality/testing.html:
+ * quality/testwriting.html:
+
2010-03-19 Maciej Stachowiak <mjs@apple.com>
Reviewed by Mark Rowe.
</div>
<ol>
-<li><p>Run the <
tt>build-webkit</tt> <a href="/coding/scripts.html">script</a>
+<li><p>Run the <
code>build-webkit</code> <a href="/coding/scripts.html">script</a>
to build WebKit.</p>
-<p>Use the <tt>--debug</tt> option for a debug build, which includes
+<p>Use the <code>--debug</code> option for a debug build, which includes
debugging symbols and assertions:</p>
<p class="code">build-webkit --debug</p>
</li>
</ol>
-<p>By default, <tt>build-webkit</tt> places build products in <tt>WebKit/WebKitBuild</tt>. You can specify a different build
-location on Mac in your Xcode preferences. On Windows, the <tt>WEBKITOUTPUTDIR</tt> environment variable can be used to
-set a different build products location. If you have set up a custom build location, then <tt>build-webkit</tt> will
+<p>By default, <code>build-webkit</code> places build products in <code>WebKit/WebKitBuild</code>. You can specify a different build
+location on Mac in your Xcode preferences. On Windows, the <code>WEBKITOUTPUTDIR</code> environment variable can be used to
+set a different build products location. If you have set up a custom build location, then <code>build-webkit</code> will
place the build products there.</p>
<div class="windows-instructions">
<h2>Setting a Default Configuration</h2>
<ol>
-<li><p>To set a default build configuration for <tt>build-webkit</tt> and
+<li><p>To set a default build configuration for <code>build-webkit</code> and
other <a href="/coding/scripts.html">scripts</a>, use the
-<tt>set-webkit-configuration</tt> script:</p>
+<code>set-webkit-configuration</code> script:</p>
<p class="code">set-webkit-configuration --debug</p>
<p class="code">set-webkit-configuration --release</p>
</li>
<h4>Windows</h4>
<ol>
<li><p>Install the WebKit Support Libraries</p>
-<p>Download the <a href="http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html">WebKit Support Libraries</a> to the root of your source tree (<tt>C:\cygwin\home\<username>\WebKit</tt>).</p>
-<p>If the file is incorrectly named, rename it to <tt>WebKitSupportLibrary.zip</tt>. Do not extract its contents.</p>
+<p>Download the <a href="http://developer.apple.com/opensource/internet/webkit_sptlib_agree.html">WebKit Support Libraries</a> to the root of your source tree (<code>C:\cygwin\home\<username>\WebKit</code>).</p>
+<p>If the file is incorrectly named, rename it to <code>WebKitSupportLibrary.zip</code>. Do not extract its contents.</p>
</ol>
</div>
<ol>
-<li><p>Run the <
tt>update-webkit</tt> <a href="/coding/scripts.html">script</a>
+<li><p>Run the <
code>update-webkit</code> <a href="/coding/scripts.html">script</a>
to update your source tree.</p>
<p>If you downloaded the tarball, this will bring it up to date. Windows users
must always execute this command after first obtaining the code, since it will
<a href="build.html">building WebKit</a>.</p>
<h2>Keeping up to Date</h2>
-<p>At any time, you can rerun the <tt>update-webkit</tt> script to update
+<p>At any time, you can rerun the <code>update-webkit</code> script to update
your source tree.</p>
<?php
<p>Each WebKit component -- JavaScriptCore, WebCore, and WebKit -- contains its own Xcode project. Open the project belonging to the component you want to debug.</p>
</li>
<li><p>Set the project's build products location</p>
-<p>To find the WebKit you built, Xcode needs to know the build products location that <tt>build-webkit</tt> used. You can set the build products location from the project's Info window.</p>
+<p>To find the WebKit you built, Xcode needs to know the build products location that <code>build-webkit</code> used. You can set the build products location from the project's Info window.</p>
<img src="info-tab.png">
</li>
<li><p>Set the project's active build configuration</p>
<h2>Debugging on Windows</h2>
<p>To launch Safari in the Visual Studio or Visual C++ Express debugger, simply run:</p>
<p class="code">debug-safari</p>
-<p>This command will launch the Visual Studio debugging environment, and attach to Safari connected to the debug build of WebKit.dll. There are a few things to keep in mind:
+<p>This command will launch the Visual Studio debugging environment, and attach to Safari connected to the debug build of WebKit.dll. There are a few things to keep in mind:</p>
<ul>
<li>The instance of Safari is not running yet. You must press the F5 key (or the 'Run' button) to see anything happen.</li>
<li>If you want to set any breakpoints, you must navigate to the particular source file you wish to investigate using the "File|Open" menu.</li>
<img src="debug_vs2005.jpg">
<p>You should consider including the command-line switch '<span class="code">/console</span>'. This causes Safari to run with an open DOS shell in which output messages, created with the <span class="code">LOG</span> macro, appear.</p>
<img src="console_vs2005.jpg"></li>
-</ul></p>
-<p>Alternatively, you can build, run, and debug WebKit from inside Visual Studio by opening the solution file:
+</ul>
+<p>Alternatively, you can build, run, and debug WebKit from inside Visual Studio by opening the solution file:</p>
<ol>
<li>Launch Visual Studio.</li>
<li>Select the 'File' menu, then 'Open' > 'Project / Solution...'. Select the WebKit/win/WebKit.vcproj/WebKit.sln file and click 'Open'.</li>
<li>Right-click on the 'WebKit' project in the Solution Explorer and select 'Properties'. Under 'Configuration Properties' > 'Debugging', make sure 'Command' and 'Working Directory' are set as shown above.</li>
<li>To build, select the 'Build' menu, then 'Build Solution'. To run, select the 'Debug' menu, then 'Start Debugging'.</li>
</ol>
-</p>
<p>It is also recommended that you follow <a href="http://developer.apple.com/internet/safari/windows_symbols_agree.html">the instructions to configure Visual Studio to use Apple's Safari for Windows symbol server</a>. This will give Visual Studio the information it needs to provide reliable backtraces when pausing in the debugger or when a crash occurs.</p>
</div>
<h2>Running WebKit</h2>
<ol>
-<li><p>Execute the <
tt>run-safari</tt> <a href="/coding/scripts.html">script</a>
+<li><p>Execute the <
code>run-safari</code> <a href="/coding/scripts.html">script</a>
to run Safari with the WebKit version you <a href="build.html">built</a>.</p>
-<p>Use the <tt>--debug</tt> option for a debug build:</p>
+<p>Use the <code>--debug</code> option for a debug build:</p>
<p class="code">run-safari --debug</p>
</li>
</ol>
<div class="mac-instructions">
<h4>Mac OS X</h4>
-<p>The <tt>run-safari</tt> script sets the <tt>DYLD_FRAMEWORK_PATH</tt> environment variable to point to your build products,
-and then launches /Applications/Safari.app. <tt>DYLD_FRAMEWORK_PATH</tt> tells the system loader to prefer your build products over the frameworks installed in /System/Library/Frameworks.</p>
+<p>The <code>run-safari</code> script sets the <code>DYLD_FRAMEWORK_PATH</code> environment variable to point to your build products,
+and then launches /Applications/Safari.app. <code>DYLD_FRAMEWORK_PATH</code> tells the system loader to prefer your build products over the frameworks installed in /System/Library/Frameworks.</p>
</div>
<div class="windows-instructions">
<h4>Windows</h4>
-<p>The <tt>run-safari</tt> script launches the Safari executable with the <tt>/frameworkPath</tt> command line switch set to point to your build products. The <tt>/debug</tt> command line switch will be set if you pass --debug to <tt>run-safari.</tt></p>
+<p>The <code>run-safari</code> script launches the Safari executable with the <code>/frameworkPath</code> command line switch set to point to your build products. The <code>/debug</code> command line switch will be set if you pass --debug to <code>run-safari.</code></p>
</div>
<?php
<h4>Windows</h4>
<ol>
<li><p>If you own Visual Studio 2005 (newer versions of Visual Studio are currently unsupported):</p>
-<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?familyid=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC&displaylang=en">Microsoft Visual Studio 2005 Team Suite Service Pack 1</a>.</p>
-<p>If you are building from Vista, install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en">Service Pack 1 Update for Windows Vista</a>.</p>
-<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197&displaylang=en">Visual Studio 2005 Service Pack 1 ATL Security Update</a>.</p>
-<p>Install the following hotfixes to improve Visual Studio's performance and responsiveness:
+<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?familyid=BB4A75AB-E2D4-4C96-B39D-37BAF6B5B1DC&displaylang=en">Microsoft Visual Studio 2005 Team Suite Service Pack 1</a>.</p>
+<p>If you are building from Vista, install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en">Service Pack 1 Update for Windows Vista</a>.</p>
+<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197&displaylang=en">Visual Studio 2005 Service Pack 1 ATL Security Update</a>.</p>
+<p>Install the following hotfixes to improve Visual Studio's performance and responsiveness:</p>
<ol>
<li><a target="installtools" href="http://code.msdn.microsoft.com/KB918559">KB918559</a></li>
<li><a target="installtools" href="http://code.msdn.microsoft.com/KB935225">KB935225</a></li>
<li><a target="installtools" href="http://code.msdn.microsoft.com/KB943969">KB943969</a></li>
<li><a target="installtools" href="http://code.msdn.microsoft.com/KB947315">KB947315</a></li>
</ol>
-</p>
<p>Use the default options for these installations.</p>
<li><p>If not, you can use Visual C++ Express 2005 (newer versions of Visual C++ Express Edition are currently unsupported):</p>
<p>Install <a target="installtools" href="http://go.microsoft.com/fwlink/?LinkId=51410">Visual C++ 2005 Express</a>.</p>
<p>Install <a target="installtools" href="http://download.microsoft.com/download/7/7/3/7737290f-98e8-45bf-9075-85cc6ae34bf1/VS80sp1-KB926748-X86-INTL.exe">Microsoft Visual C++ Express 2005 Service Pack 1</a>.</p>
-<p>If you are building from Vista, install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en">Service Pack 1 Update for Windows Vista</a>.</p>
-<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197&displaylang=en">Visual Studio 2005 Service Pack 1 ATL Security Update</a>.</p>
-<p>Install the <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?familyid=0baf2b35-c656-4969-ace8-e4c0c0716adb&displaylang=en">Windows Server 2003 R2 Platform SDK</a>, then follow steps 2 and 3 of “<a target="installtools" href="http://msdn.microsoft.com/en-us/library/ms235626(VS.80).aspx">How to: Use Visual C++ Express Edition with the Microsoft Platform SDK</a>.”</p>
+<p>If you are building from Vista, install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&displaylang=en">Service Pack 1 Update for Windows Vista</a>.</p>
+<p>Install <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?FamilyID=7c8729dc-06a2-4538-a90d-ff9464dc0197&displaylang=en">Visual Studio 2005 Service Pack 1 ATL Security Update</a>.</p>
+<p>Install the <a target="installtools" href="http://www.microsoft.com/downloads/details.aspx?familyid=0baf2b35-c656-4969-ace8-e4c0c0716adb&
amp;displaylang=en">Windows Server 2003 R2 Platform SDK</a>, then follow steps 2 and 3 of “<a target="installtools" href="http://msdn.microsoft.com/en-us/library/ms235626(VS.80).aspx">How to: Use Visual C++ Express Edition with the Microsoft Platform SDK</a>.”</p>
<p>Use the default options for all installations.</p>
<p>In addition to the paths specified in step 3 of the Platform SDK installation instructions, you must also add the following include path. Update the Visual C++ directories in the Projects and Solutions section in the Options dialog box:</p>
<p style="font-size:10px">C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\mfc</p>
packages.
<p>Download <a
href="http://svn.webkit.org/repository/webkit/trunk/WebKitTools/CygwinDownloader/cygwin-downloader.zip">cygwin-downloader.zip</a>.</p>
-<p>Right-click <tt>cygwin-downloader.zip</tt> and choose <b>Extract All...</b>.
+<p>Right-click <code>cygwin-downloader.zip</code> and choose <b>Extract All...</b>.
Keep all the default options and click <b>Next</b> until the file is extracted and the cygwin-downloader folder opens.</p>
-<p>Double-click <tt>cygwin-downloader.exe</tt>. This will download all the Cygwin packages you need.</p>
+<p>Double-click <code>cygwin-downloader.exe</code>. This will download all the Cygwin packages you need.</p>
<p>When all the packages have finished downloading, the Cygwin installer will launch. Choose <b>Install from Local Directory</b>, then click <b>Next</b> until the install is complete. If you are running Vista, the installer won't be able to launch automatically, so you will have to manually launch Cygwin's Setup.exe.</p>
<P>Vista may warn you that Cygwin did not install correctly. Ignore this warning and tell Vista that the install was successful.</p>
<p>If you are running Vista, click on the Start menu, enter the following command, and press Enter:</p>
<li>Do not place spaces before comma and semicolon.
<h4 class="right">Right:</h4>
<pre class="code">
-for (int i = 0; i < 10; i++)
+for (int i = 0; i < 10; i++)
doSomething();
f(a, b);
<h4 class="wrong">Wrong:</h4>
<pre class="code">
-for (int i = 0 ; i < 10 ; i++)
+for (int i = 0 ; i < 10 ; i++)
doSomething();
f(a , b) ;
<li>Choose or create a <a href="#bugreport">bug report</a> to work on.</li>
<li><a href="#writecode">Develop</a> your changes.</li>
<li>Make sure your changes meet the <a href="/coding/coding-style.html">code
- style guidelines</a>. The <tt>check-webkit-style</tt> script may be of
+ style guidelines</a>. The <code>check-webkit-style</code> script may be of
help.</li>
- <li>Run the layout tests using the <tt>run-webkit-tests</tt> script and make sure they all pass.
+ <li>Run the layout tests using the <code>run-webkit-tests</code> script and make sure they all pass.
See the <a href="/quality/testwriting.html">testing page</a> for more information, as well as what you need to do if you've modified JavaScriptCore.</li>
<li>Add any <a href="#newfiles">new files</a> to your working directory.</li>
- <li>Prepare a change log entry. You may have to add entries to multiple ChangeLogs. The <
tt>prepare-ChangeLog</tt> script will create stub entries for you. See the <a href="#changelogs">paragraph about ChangeLogs</a> below.</li>
- <li>Create the patch using the <tt>svn-create-patch</tt> script.</li>
+ <li>Prepare a change log entry. You may have to add entries to multiple ChangeLogs. The <
code>prepare-ChangeLog</code> script will create stub entries for you. See the <a href="#changelogs">paragraph about ChangeLogs</a> below.</li>
+ <li>Create the patch using the <code>svn-create-patch</code> script.</li>
<li><a href="#submit">Submit</a> your patch for review to
<a href="https://bugs.webkit.org/">bugs.webkit.org</a>.</li>
<li>Make any changes recommended by the reviewer.</li>
work. Below are sample copyright lines for an individual contributor
and a company:
-<p><tt>Copyright (C) 2010 John Smith (jsmith@example.com)</tt></p>
-<p><tt>Copyright (C) 2010 Company Inc. All rights reserved.</tt></p>
+<p><code>Copyright (C) 2010 John Smith (jsmith@example.com)</code></p>
+<p><code>Copyright (C) 2010 Company Inc. All rights reserved.</code></p>
<p>In addition, make sure that any new source code and script files
you introduce contain license text at the beginning of the file.
which should not be cleaned up.</p>
<h3>Regression tests</h3>
-<p>Once you have made your changes, you need to run the regression tests, which is done via the <tt>run-webkit-tests</tt> script.
+<p>Once you have made your changes, you need to run the regression tests, which is done via the <code>run-webkit-tests</code> script.
All tests must pass. Patches will not be landed in the tree if they break existing layout tests.</p>
<p>For any feature that affects the layout engine, a new regression test must be constructed. If you provide a patch that fixes a bug,
<h3 id="newfiles">Add new files to your working directory</h3>
<p>If your changes include adding new files (like new layout tests),
-use the <tt>svn add</tt> command to mark these files for addition to the
+use the <code>svn add</code> command to mark these files for addition to the
repository. If you do not do this, the new files will be missing from
the patch file you generate below.</p>
-<p>You can learn more about Subversion commands like <tt>svn add</tt>
+<p>You can learn more about Subversion commands like <code>svn add</code>
from the online book <a class="book" href="http://svnbook.red-bean.com/">
-Version Control with Subversion</a> and by using the <tt>svn help</tt>
+Version Control with Subversion</a> and by using the <code>svn help</code>
command.</p>
<h3 id="changelogs">ChangeLog files</h3>
-<p>ChangeLogs are simple text files which provide historical documentation for all changes to the WebKit project. All patches require an entry to the ChangeLog. The <tt>prepare-ChangeLog</tt> script will create a basic entry containing a list of all files that have been changed. The first line contains the date, your full name, and your email address. Use this to write up a brief summary of the changes you've made. Don't worry about the "Reviewed by NOBODY (OOPS!)" line, the person landing your patch will fill this in.</p>
+<p>ChangeLogs are simple text files which provide historical documentation for all changes to the WebKit project. All patches require an entry to the ChangeLog. The <code>prepare-ChangeLog</code> script will create a basic entry containing a list of all files that have been changed. The first line contains the date, your full name, and your email address. Use this to write up a brief summary of the changes you've made. Don't worry about the "Reviewed by NOBODY (OOPS!)" line, the person landing your patch will fill this in.</p>
-<p>There is one ChangeLog per top-level directory, if you changed code and tests you will need to edit at least two ChangeLogs. The <tt>prepare-ChangeLog</tt> script will create a stub entries for you. You should edit these stubs to describe your change, including the full url to the bug (<a href="http://trac.webkit.org/changeset/43259">example entry</a>, note that you can use <tt>--bug</tt> flag). (You should set EMAIL_ADDRESS and CHANGE_LOG_NAME in your environment if you will be running this script frequently.)</p>
+<p>There is one ChangeLog per top-level directory, if you changed code and tests you will need to edit at least two ChangeLogs. The <code>prepare-ChangeLog</code> script will create a stub entries for you. You should edit these stubs to describe your change, including the full url to the bug (<a href="http://trac.webkit.org/changeset/43259">example entry</a>, note that you can use <code>--bug</code> flag). (You should set EMAIL_ADDRESS and CHANGE_LOG_NAME in your environment if you will be running this script frequently.)</p>
<p>The line WARNING: NO TEST CASES ADDED OR CHANGED appears if prepare-ChangeLog did not detect the addition of test cases. If your patch does not require test cases (or test cases are not possible), you should include a line stating such. Otherwise all changes require test cases which should be mentioned in the ChangeLog.</p>
<h3>Create the patch</h3>
-<p>WebKit uses <tt>svn-create-patch</tt> to create patches. The
-<tt>svn-create-patch</tt> script is a small wrapper around Subversion's
-<tt>diff</tt> command that better handles moved, added, and deleted files.
+<p>WebKit uses <code>svn-create-patch</code> to create patches. The
+<code>svn-create-patch</code> script is a small wrapper around Subversion's
+<code>diff</code> command that better handles moved, added, and deleted files.
This command is best run from the top level of your checkout
to make sure no changes are left out of your patch. It is not necessary to
break a patch into multiple files.</p>
-<p>The <tt>svn-create-patch</tt> script does not create a file automatically.
+<p>The <code>svn-create-patch</code> script does not create a file automatically.
You need to redirect the output yourself using something like--</p>
<p class="code">svn-create-patch > MyExcellentPatch.txt</p>
<p><img src="images/contribute_mark_review.png"
alt="Bugzilla patch-submission options"></p>
-<p>The patch checkbox and the <tt>review:?</tt> flag signal to
+<p>The patch checkbox and the <code>review:?</code> flag signal to
WebKit reviewers that your patch is ready for review.
Setting the review flag also sends an automatic e-mail to the
<a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">
<p>A WebKit reviewer must approve your patch before WebKit can accept
it into the source control repository.
A reviewer will typically either approve your patch
-(by responding with an <tt>r=me</tt> in the bug report and marking the patch <tt>review:+</tt>) or request revisions
-to your patch (and mark the patch <tt>review:-</tt>). In rare cases a patch may be permanently rejected, meaning that the reviewer
+(by responding with an <code>r=me</code> in the bug report and marking the patch <code>review:+</code>) or request revisions
+to your patch (and mark the patch <code>review:-</code>). In rare cases a patch may be permanently rejected, meaning that the reviewer
believes the feature should never be committed to the tree. The review process can consist of multiple iterations between you and
the reviewer as you submit revised patches.</p>
<p>Changes should succeed on all platforms, but it can be difficult to test on every platform WebKit supports. Be certain that your change does not introduce new test failures on the high-traffic Mac or Windows ports by comparing the list of failing tests before and after your change. Your change must at least compile on all platforms.</p>
<h4 id="commitqueue">Optional: Use of the WebKit Commit Bot</h4>
-<p>WebKit provides an automated system (commit-queue) for landing patches for any who would like to use it. To use the commit-queue, set the <
tt>commit-queue:?</tt> flag on your patch. A committer will set <tt>commit-queue:+</tt> and an automated process will download, build, run the layout tests, and submit your patch on your behalf. If the <a href="http://build.webkit.org/">WebKit buildbots</a> are passing, your patch should be landed within 15 minutes after <tt>commit-queue:+</tt> is set. See the <a href="https://trac.webkit.org/wiki/CommitQueue">commit-queue documentation</a> for more information.</p>
+<p>WebKit provides an automated system (commit-queue) for landing patches for any who would like to use it. To use the commit-queue, set the <
code>commit-queue:?</code> flag on your patch. A committer will set <code>commit-queue:+</code> and an automated process will download, build, run the layout tests, and submit your patch on your behalf. If the <a href="http://build.webkit.org/">WebKit buildbots</a> are passing, your patch should be landed within 15 minutes after <code>commit-queue:+</code> is set. See the <a href="https://trac.webkit.org/wiki/CommitQueue">commit-queue documentation</a> for more information.</p>
<h2>Obtaining Commit and Review Privileges</h2>
<p>Our <a href="commit-review-policy.html">Committer and Reviewer policy</a> provides details on obtaining commit and review privileges.</p>
include("../header.inc");
?>
-<style type="text/css">
- .asciiart {
- background-color: #eee;
- padding: 1em;
- margin-left: 2em;
- margin-right: 2em;
- overflow-x: auto;
- }
-</style>
-
<h1>Major Objects in WebCore</h1>
<div>Adam Barth</div>
<div>first draft, 2009-08-12</div>
.../....|...............................................|..........
/ | \/ Replaced after navigation \/ |
/ | |
-/<------|<-- Ptrs to Frame are null after navigation[1] |
+/<------|<-- Ptrs to Frame are null after navigation[1] |
| | |
| +-----+-----+ +-------------+ |
-| | DOMWindow |<--impl--+ JSDOMWindow |<------window----+
+| | DOMWindow |<--impl--+ JSDOMWindow |<------window----+
| +-----+-----+ +-------------+
| |
-| |<-- Can be null for Documents created by XMLHttpRequest
+| |<-- Can be null for Documents created by XMLHttpRequest
| |
| +-----+-----+ +-------------+
-+-+ Document |<--impl--+ JSDocument |
++-+ Document |<--impl--+ JSDocument |
+-----+-----+ +-------------+
|
- |<-- Can be null for DocumentType objects
+ |<-- Can be null for DocumentType objects
|
+---+---+ +--------+
- | Node |<---impl---| JSNode |
+ | Node |<---impl---| JSNode |
+-------+ +--------+
</pre>
padding: 0 1em;
margin: 1em 0;
}
+
+.asciiart {
+ background-color: #eee;
+ padding: 1em;
+ margin-left: 2em;
+ margin-right: 2em;
+ overflow-x: auto;
+}
<a href="editingToolbar"><h2>Editing Toolbar</h2></a>
<span class="datestamp">Added November 4th, 2007</span>
-<p>The editing toolbar shows off a rich HTML editing toolbar in WebKit. It uses JavaScript and CSS to fade in and out and to implement the buttons that apply text formating and alignment. Click in the text area to see the toolbar appear.
+<p>The editing toolbar shows off a rich HTML editing toolbar in WebKit. It uses JavaScript and CSS to fade in and out and to implement the buttons that apply text formating and alignment. Click in the text area to see the toolbar appear.</p>
<a href="sticky-notes"><h2>Sticky Notes</h2></a>
<span class="datestamp">Added October 19th, 2007</span>
<!DOCTYPE html>
<html>
<head>
- <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+ <meta charset="utf-8">
<meta name="robots" content="noodp">
<title>The WebKit Open Source Project<?php if (isset($title)) { echo " - " . $title; } ?></title>
<link rel="stylesheet" type="text/css" href="/css/ie.css">
<![endif]-->
- <script type="text/javascript">
+ <script>
pic1 = new Image(8,9);
pic1.src="/images/green-bullet.png";
pic2 = new Image(8,9);
<dd><a href="../../quality/reporting.html">Report bugs</a> to us for any problems you find. Get bugs into our database so that we
can track the issue and screen the bug.</dd>
<dt>Reduce Bugs</dt>
-<dd>Scan the bugs in the <tt>New Bugs</tt> component and help attach reductions and minimal failing test cases. Only when bugs are
+<dd>Scan the bugs in the <code>New Bugs</code> component and help attach reductions and minimal failing test cases. Only when bugs are
screened properly will a developer be able to determine the root cause of the problem and move it into the appropriate component.
<i>This is one of the most important ways you can help improve WebKit.</i>
<dt>Create New Tests</dt>
<?php
include("../../footer.inc");
-?>
\ No newline at end of file
+?>
Complete support is measured by passing the CSS1 test suite.
<dt>Finish CSS2.1 Support</dt>
-<dd>Most of CSS2.1 has been implemented in WebKit, but a few holes remain. The new white-space values <tt>pre-wrap</tt> and <tt>pre-line</tt> are not yet
+<dd>Most of CSS2.1 has been implemented in WebKit, but a few holes remain. The new white-space values <code>pre-wrap</code> and <code>pre-line</code> are not yet
supported. Some of these features have been implemented in the current KHTML tree, and a merge may be possible for
some of these features.
within the project pages themselves.
<dt>Existing Documentation</dt>
-<dd><a href="http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/DisplayWebContent.html" />Introduction to WebKit Objective-C Programming Guide</a></dd>
+<dd><a href="http://developer.apple.com/documentation/Cocoa/Conceptual/DisplayWebContent/DisplayWebContent.html">Introduction to WebKit Objective-C Programming Guide</a></dd>
<dd>[TODO: Add links to other existing Apple docs]</dd>
</dl>
<dt>Hackability</dt>
<dd>To make rapid progress possible, we try to keep the code relatively easy to understand, even though web technologies are often complex. We try to use straightforward algorithms and data structures when possible, we try to write clear, maintainable code, and we continue to improve names and code structure to aid understanding. When tricky "rocket science" code is truly needed to solve some problem, we try to keep it bottled up behind clean interfaces. In addition, we make heavy use of automated regression tests as a safety net, to allow aggressive changes with less risk of regressions.</dd>
-
+</dl>
<h3>Non-Goals</h3>
in the extensions to HTML proposed by the WhatWG in the <a href="http://whatwg.org/specs/web-apps/current-work/">Web Apps specification</a>.
<dt><a href="editing/index.html">HTML Editing</a>
-<dd>The HTML editing project provides rich text editing capabilities both as WebKit API for applications and through support of <tt>contentEditable</tt>
-and <tt>designMode</tt> for use in Web pages.
+<dd>The HTML editing project provides rich text editing capabilities both as WebKit API for applications and through support of <code>contentEditable</code>
+and <code>designMode</code> for use in Web pages.
<dt><a href="forms/index.html">HTML Forms</a>
<dd>The HTML form controls project is about the code to support the form controls that are available in HTML and XHTML.
<p>More information about this project is provided on the <a href="https://trac.webkit.org/wiki/MathML">MathML Wiki page</a>.</p>
<h3>Get Involved!</h3>
-<p><a href="../../contact.html">Come find us</a> on <tt>#webkit</tt> to get involved.</p>
+<p><a href="../../contact.html">Come find us</a> on <code>#webkit</code> to get involved.</p>
<?php
include("../../footer.inc");
<p>This document describes the current guidelines for assigning priorities to Web Kit bugs in <a href="https://bugs.webkit.org/">Bugzilla</a>.
The relevant bugs are all of those whose product is "WebKit".</p>
- <a name="standardrules"></a><h3>Standard priority rules</h3>
+ <a id="standardrules"></a><h3>Standard priority rules</h3>
<p>Each bug is assigned the first appropriate priority listed below
from top to bottom.</p>
projects who might use it, that's why it's still there.</li>
</ul>
- <a name="commonadjustments"></a><h3>Common adjustments to priority</h3>
+ <a id="commonadjustments"></a><h3>Common adjustments to priority</h3>
<ul>
<li>If there is a workaround, the priority may be moved down.</li>
<li>If a bug gets a lot of duplicates, the priority may be moved up.</li>
Please select the WebKit version you were using when the bug occurred, or the closest matching version.
</p>
<p>
- Versions of WebKit that are not part of a Safari release have a <tt>+</tt> after the version number, and their version number
- is generally higher then the latest released version of WebKit. So, for example, <tt>528+</tt> is an unofficial build of WebKit
- that is newer than the <tt>525.x</tt> version that shipped as part of Safari 3.1.2.
+ Versions of WebKit that are not part of a Safari release have a <code>+</code> after the version number, and their version number
+ is generally higher then the latest released version of WebKit. So, for example, <code>528+</code> is an unofficial build of WebKit
+ that is newer than the <code>525.x</code> version that shipped as part of Safari 3.1.2.
</p>
<div style="display: none; text-align: center; font-weight: bold;" id="webkit_version"></div>
<script type="text/javascript">
<li><b>Component</b>
<p>If you know the precise cause of a bug (i.e., you've reduced it to a failing test case and know the reason), then you can
- assign a bug to a specific component such as <tt>CSS</tt> or <tt>HTML Editing</tt>.
- <p>If, however, there is any doubt in your mind as to the cause of the bug, then file it under <tt>New Bugs</tt>. This component
+ assign a bug to a specific component such as <code>CSS</code> or <code>HTML Editing</code>.
+ <p>If, however, there is any doubt in your mind as to the cause of the bug, then file it under <code>New Bugs</code>. This component
is the place for any bugs whose cause has not yet been determined. Once someone has reduced the bug and knows the cause, then it
- will be moved from the <tt>New Bugs</tt> component to the appropriate place.</p>
+ will be moved from the <code>New Bugs</code> component to the appropriate place.</p>
</li>
<li>
<b>Platform and OS</b>
<p>Please select the platform and the OS version that your bug occurred on. If you're running on Mac OS X this would often be platform
- <tt>Macintosh</tt> and OS <tt>Mac OS X 10.5</tt> (Leopard). If you're running on Windows or Linux, please select <tt>PC</tt> for platform
+ <code>Macintosh</code> and OS <code>Mac OS X 10.5</code> (Leopard). If you're running on Windows or Linux, please select <code>PC</code> for platform
and the appropriate entry from the OS field. If your exact system is not listed, please select the closest entry and provide further
details in the description of the bug report.
</li>
<li>
<b>Severity</b>
- <p>In most cases you should leave this at <tt>normal</tt>, but if you are confident that your bug is <tt>trivial</tt> or an
- <tt>enhancement</tt>, it's helpful to specify that value. A QA person or developer will set this to some other value if
+ <p>In most cases you should leave this at <code>normal</code>, but if you are confident that your bug is <code>trivial</code> or an
+ <code>enhancement</code>, it's helpful to specify that value. A QA person or developer will set this to some other value if
appropriate.</p>
</li>
<li>If the bug is a crash, note this and note whether or not the crash is reproducible
<li>If you have tested and verified that this is a regression from a previous version of WebKit, prepend "REGRESSION: " to the summary
<li>If you know the range of revisions in which the regression occurred, add this to the summary after REGRESSION (i.e., "REGRESSION(r31201-r31211):")
- </ul>
- </li><br>
+ </ul><br>
+ </li>
<li><b>Description</b>
<p>In this field, write a more detailed explanation of the problem.</p>
the problem. You can then attach the screenshot to the bug.</li>
<li>Be as specific as possible. For instance, if you're describing a problem that occurs while scrolling, note in the bug whether you're scrolling with arrow
keys, arrow buttons, scroll thumb, clicking above or below the thumb, scroll-wheel mouse, etc.</li>
- </ul></li><br>
+ </ul><br></li>
<li><b>Keywords</b>
<p>If the bug is specific to one or more of the ports of WebKit (Qt, GTK, Wx, etc), please use any of the
<img src="mac_viewtrace.jpg" alt="Mac OS X Crash log">
</li>
<li>
- <p>If the crash report dialog does not appear or the crash is hard to reproduce, crash logs can be retrieved from the <tt>~/Library/Logs/CrashReporter</tt> folder.</p>
+ <p>If the crash report dialog does not appear or the crash is hard to reproduce, crash logs can be retrieved from the <code>~/Library/Logs/CrashReporter</code>> folder.</p>
<p>On Leopard (Mac OS X 10.5), crash logs are stored as individually dated and time stamped files. Despite having a “.crash”
extension, they are plain text files and can be attached directly to a bug report.</p>
- <p>On Tiger (Mac OS X 10.4), all crashes are logged to <tt>Safari.crash.log</tt>. This is a plain text file and can
+ <p>On Tiger (Mac OS X 10.4), all crashes are logged to <code>Safari.crash.log</code>>. This is a plain text file and can
be viewed in the default Console.app or your favorite text editor. <strong>All</strong> of Safari's crashes are logged
to this file so please only attach the last crash in it. Crashes are separated by a series of asterisks
(∗∗∗∗∗∗∗∗∗∗) for easy identification.</p>
configured to log them.</p>
<ol>
<li>
- <p>In the Start menu's Run box or from a DOS or Cygwin prompt, enter the command <tt>drwtsn32 -i</tt>.</p>
+ <p>In the Start menu's Run box or from a DOS or Cygwin prompt, enter the command <code>drwtsn32 -i</code>>.</p>
<img src="win_installwatson.jpg" alt="Dr Watson install command">
</li>
<li>
<img src="win_watsoninstalled.jpg" alt="Dr Watson was installed box">
</li>
<li>
- <p>Crash information will now be logged to the <tt>user.dmp</tt> file in
- <tt>C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\</tt>.</p>
+ <p>Crash information will now be logged to the <code>user.dmp</code>> file in
+ <code>C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\</code>>.</p>
- <p>Dr. Watson will create a <tt>user.dmp</tt> file that records what WebKit was doing when it crashed.
+ <p>Dr. Watson will create a <code>user.dmp</code>> file that records what WebKit was doing when it crashed.
Be careful as it is overwritten with every crash.</p>
- <p>When reporting a WebKit bug, please upload the <tt>user.dmp</tt> file if possible.</p>
+ <p>When reporting a WebKit bug, please upload the <code>user.dmp</code>> file if possible.</p>
</li>
<li>
- <p>Running <tt>drwtsn32</tt> without any options or switches will bring up a window that allows you to change various
+ <p>Running <code>drwtsn32</code>> without any options or switches will bring up a window that allows you to change various
setting such as moving the log folder to a more easily accessible location or throwing a visual alert letting
you know it caught the crash.</p>
<img src="win_watsongui.jpg" alt="Dr Watson window">
By default, Vista uploads the crash logs to Microsoft, but does not save a local copy. This is configurable via the registry.</p>
<ol>
<li>
- <p>Save the following text to a file named <tt>wer.reg</tt>:</p><tt style="white-space:pre">Windows Registry Editor Version 5.00
+ <p>Save the following text to a file named <code>wer.reg</code>>:</p><tt style="white-space:pre">Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"ForceQueue"=dword:00000001
-</tt>
+</code>>
</li>
<li><p>Double-click the file from Windows Explorer and respond affirmatively to any prompts.</p></li>
<li><p>Reboot</p></li>
</ol>
<p>
- The next time Safari (or any other application) crashes, the crash information will be written into a folder located inside <tt>%LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue</tt>.
+ The next time Safari (or any other application) crashes, the crash information will be written into a folder located inside <code>%LOCALAPPDATA%\Microsoft\Windows\WER\ReportQueue</code>>.
Check the modification date to make sure you are using the correct file.
</p>
<p>Be sure to include the following files in your bug report:</p>
<dl style="margin-left:2em">
- <dt><tt>WER<em>xxxx</em>.tmp.mdmp</tt></dt>
+ <dt><code>WER<em>xxxx</em>.tmp.mdmp</code>></dt>
<dd>This is the most important file. It contains the crash dump that can be opened inside Visual Studio or other Windows debuggers.</dd>
- <dt><tt>WER<em>xxxx</em>.tmp.version.txt</tt></dt>
+ <dt><code>WER<em>xxxx</em>.tmp.version.txt</code>></dt>
<dd>Contains the operating system version and other hardware information.</dd>
- <dt><tt>WER<em>xxxx</em>.tmp.appcompat.txt</tt></dt>
+ <dt><code>WER<em>xxxx</em>.tmp.appcompat.txt</code>></dt>
<dd>Lists all of the DLLs loaded at the time of the crash with their version information.</dd>
</dl>
</div>
<h3>Fresh, Unconfirmed Bugs</h3>
-<p>A freshly-created bug starts out in state <tt>UNCONFIRMED</tt>. Often it is in component <tt>New Bugs</tt>, but
+<p>A freshly-created bug starts out in state <code>UNCONFIRMED</code>. Often it is in component <code>New Bugs</code>, but
some bugs will be given an initial component in the initial <a href="reporting.html">bug-reporting step</a>.</p>
-<h3><a name="confirming"></a>Confirming Bugs</h3>
+<h3><a id="confirming"></a>Confirming Bugs</h3>
-<p>The next step is for someone with Bugzilla <tt>canConfirm</tt> privileges to review the unconfirmed bug and
+<p>The next step is for someone with Bugzilla <code>canConfirm</code> privileges to review the unconfirmed bug and
decide whether it has enough useful information to move forward. The possible changes to the bug at this step include the following:</p>
<ul>
-<li>Resolution changed to <tt>DUPLICATE</tt> if the bug is determined to have the same cause as a bug reported earlier.</li>
-<li>Resolution changed to <tt>WORKSFORME</tt> if the bug seems to not be present in the latest sources.</li>
-<li>Resolution changed to <tt>INVALID</tt> if the bug does not describe a problem with WebKit.</li>
-<li>Resolution changed to <tt>WONTFIX</tt> in the rare case that the bug seems valid but there's a specific reason why it
+<li>Resolution changed to <code>DUPLICATE</code> if the bug is determined to have the same cause as a bug reported earlier.</li>
+<li>Resolution changed to <code>WORKSFORME</code> if the bug seems to not be present in the latest sources.</li>
+<li>Resolution changed to <code>INVALID</code> if the bug does not describe a problem with WebKit.</li>
+<li>Resolution changed to <code>WONTFIX</code> in the rare case that the bug seems valid but there's a specific reason why it
should not be fixed in WebKit (usually this would be a cross-browser compatibility issue).</li>
<li>Comments/questions added if the bug does not have enough information to move forward.</li>
-<li>Status changed to <tt>NEW</tt> if the bug is reproducible with the latest sources on Mac OS X or otherwise has enough information to move forward.
+<li>Status changed to <code>NEW</code> if the bug is reproducible with the latest sources on Mac OS X or otherwise has enough information to move forward.
If the bug is not reproducible with the latest sources, but appears to occur only on the platform stated in the platform field,
-the <tt>PlatformOnly</tt> keyword is added as well as setting the status to <tt>NEW</tt>.
-Along with changing the status, the component should also be set to an appropriate one more specific than <tt>New Bugs</tt> if necessary.</li>
+the <code>PlatformOnly</code> keyword is added as well as setting the status to <code>NEW</code>.
+Along with changing the status, the component should also be set to an appropriate one more specific than <code>New Bugs</code> if necessary.</li>
</ul>
<h3>Analyzing Bugs</h3>
<p>Each bug is initially assigned to the person designated as owner of the component. The assignee should move the bug from status
-<tt>NEW</tt> to status <tt>ASSIGNED</tt> after they have read the bug and are satisfied that it represents a real problem in WebKit.
+<code>NEW</code> to status <code>ASSIGNED</code> after they have read the bug and are satisfied that it represents a real problem in WebKit.
If they are not satisfied about this, they should perform one of the actions mentioned in the <a href="#confirming">Confirming Bugs</a> section above.
-The same procedure is followed for bugs with status <
tt>REOPENED</tt> (see <a href="#verifying">Verifying Fixes</a> below).</p>
+The same procedure is followed for bugs with status <
code>REOPENED</code> (see <a href="#verifying">Verifying Fixes</a> below).</p>
<p>The assignee represents the person who is expected to take the next step in investigating or fixing a bug. If someone other than the assignee is
investigating or fixing a bug, the assignee should be changed to the person doing the work. This helps prevent duplicated work. It's always helpful to add
<h3>Proposing Fixes</h3>
-<p>A proposed patch should be added as a new attachment. The attachment should have the <tt>patch</tt> checkbox checked, and the <tt>review</tt> flag set to <tt>?</tt>. This
+<p>A proposed patch should be added as a new attachment. The attachment should have the <code>patch</code> checkbox checked, and the <code>review</code> flag set to <code>?</code>. This
marks the patch as awaiting review. If the patch requires the specialized knowledge of a particular reviewer, the submitter or another reviewer should put
-the requested reviewer's email address in the <tt>Requestee</tt> field. Otherwise this field should be left empty. The state is left at <tt>ASSIGNED</tt> at
-this point; it isn't changed to <tt>FIXED</tt> until a fix has been checked into the source tree.</p>
+the requested reviewer's email address in the <code>Requestee</code> field. Otherwise this field should be left empty. The state is left at <code>ASSIGNED</code> at
+this point; it isn't changed to <code>FIXED</code> until a fix has been checked into the source tree.</p>
<p>When the review flag's state is changed, or when a comment is made in the Edit form for an attachment, email is automatically sent to
the <a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews</a> mailing list. The reviewers all subscribe to
this list, and anyone else is free to do so as well.</p>
-<p>If the submitter of a patch changes their mind about wanting a review, they should clear the <tt>review</tt> flag by choosing the
+<p>If the submitter of a patch changes their mind about wanting a review, they should clear the <code>review</code> flag by choosing the
blank choice in the review pop-menu.</p>
<p>More details about how to prepare code changes can be found <a href="../coding/contributing.html">elsewhere on this site</a>.</p>
<h3>Reviewing Proposed Fixes</h3>
-<p>A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the <tt>review</tt> flag to <tt>+</tt>.
+<p>A reviewer will read through each proposed patch. If the patch is ready to commit, the reviewer will change the <code>review</code> flag to <code>+</code>.
For clarity, it's helpful for the reviewer to add a comment when approving a patch. Often this comment is just "r=me", which is simply shorthand for
"I have reviewed this patch and it's ready to commit".</p>
The bug fix and test cases might be fine but the <a href="../coding/coding-style.html">coding style</a> might be incorrect. The reviewer should always
explain in detail why a patch is not ready to commit, so the submitter or someone else can revise the patch.</p>
-<p>When a submitter proposes an updated patch, they should check the <tt>obsolete</tt> checkbox on the previous version of the patch. This causes it
-to appear crossed-out in the list of attachments on the bug's main page. At the same time as marking the old patch <tt>obsolete</tt>, the
-submitter should also clear the <tt>review</tt> flag. This would happen automatically in a perfect world, but doesn't currently in this one.</p>
+<p>When a submitter proposes an updated patch, they should check the <code>obsolete</code> checkbox on the previous version of the patch. This causes it
+to appear crossed-out in the list of attachments on the bug's main page. At the same time as marking the old patch <code>obsolete</code>, the
+submitter should also clear the <code>review</code> flag. This would happen automatically in a perfect world, but doesn't currently in this one.</p>
<h3>Committing Patches</h3>
<p>After a patch has been approved, someone with commit privileges in the WebKit source repository will commit the patch into the source code repository. The committer
-should change the state of the bug to <tt>FIXED</tt>; generally the assignee is left unchanged at this point.</p>
+should change the state of the bug to <code>FIXED</code>; generally the assignee is left unchanged at this point.</p>
<p>All of the
people with commit privileges should be subscribed to the <a href="http://lists.webkit.org/mailman/listinfo/webkit-reviews">webkit-reviews</a>
person who commits the bug should also change the state of the bug appropriately in the internal system. For a Radar bug the new appropriate state would be
Software Changed/Integrate.</p>
-<h3><a name="verifying"></a>Verifying Fixes</h3>
+<h3><a id="verifying"></a>Verifying Fixes</h3>
<p>After the patch for a bug has been committed, the fix still needs to be verified. Typically this step is done by the person who originally submitted the
bug report. If the submitter is not available or does not feel that they can verify the fix, the verification step can be done by anyone with bug editing
privileges who is familiar enough with the originally reported problem to be confident about
-testing it. Note that once a bug is in the <tt>FIXED</tt> state, the assignee can no longer be changed. This means that a bug that needs
+testing it. Note that once a bug is in the <code>FIXED</code> state, the assignee can no longer be changed. This means that a bug that needs
to be verified will not usually be assigned to the person expected to verify the bug.</p>
<p>To verify a bug fix, build and run the sources that include the fix, and check whether
-the originally reported problem still occurs. If the problem no longer occurs, change the resolution to <tt>VERIFIED</tt>. If the problem does still occur,
-change the resolution to <tt>REOPENED</tt> and assign it to the person who submitted the patch.</p>
+the originally reported problem still occurs. If the problem no longer occurs, change the resolution to <code>VERIFIED</code>. If the problem does still occur,
+change the resolution to <code>REOPENED</code> and assign it to the person who submitted the patch.</p>
<h3>Closing Bugs</h3>
-<p>Fixed bugs have the <tt>VERIFIED</tt> resolution until a version of WebKit that includes the fix has been publicly released. At this point,
-the resolution is changed to <tt>CLOSED</tt>.
+<p>Fixed bugs have the <code>VERIFIED</code> resolution until a version of WebKit that includes the fix has been publicly released. At this point,
+the resolution is changed to <code>CLOSED</code>.
<?php
include("../footer.inc");
<p>Before patches can land in any of the frameworks in the repository, the
layout regression tests must pass. To run these tests, execute the
-<
tt>run-webkit-tests</tt> <a href="/coding/scripts.html">script</a>.</p>
+<
code>run-webkit-tests</code> <a href="/coding/scripts.html">script</a>.</p>
<p>The script will dump the render trees for all of the pages and diff the results against the expected correct results. If no
differences are found, then the patch has passed the tests. If any tests fail, then the patch cannot be committed until the
<table>
<tr>
- <td valign="top">
+ <td style="vertical-align: top">
<ul>
<li>Arrays</li>
<li>Booleans</li>
<li>Functions</li>
</ul>
</td>
- <td valign="top">
+ <td style="vertical-align: top">
<ul>
<li>Global Object</li>
<li>Math</li>
<li>Objects</li>
</ul>
</td>
- <td valign="top">
+ <td style="vertical-align: top">
<ul>
<li>Regular Expressions</li>
<li>Strings</li>
<h3>How to run the tests</h3>
-<p>Execute the <
tt>run-javascriptcore-tests</tt> <a href="/coding/scripts.html">script</a>.
+<p>Execute the <
code>run-javascriptcore-tests</code> <a href="/coding/scripts.html">script</a>.
The script will run all the tests and summarize how the results differ
from what is currently expected.</p>
<h3>What just happened</h3>
<p>
-After all the test runs have finished the results of tests are saved to <tt>actual.html</tt>.
+After all the test runs have finished the results of tests are saved to <code>actual.html</code>.
The script the compares these results from your local tree against what is expected to pass/fail from the tip of tree.
If there are any regressions caused by your changes you'll be made aware of them.
If you fixed a bug that caused an existing failure, you'll also be made aware of what specific test your fix affected.
<h3>What happens if I caused a regression?</h3>
<p>It's not the end of the world. Go back and fix your bug and rerun
-<tt>run-javascriptcore-tests</tt> as many times as necessary.</p>
+<code>run-javascriptcore-tests</code> as many times as necessary.</p>
<?php
include("../footer.inc");
failed.
</ol>
-<p>An example of a layout test that follows these guidelines is <tt>fast/events/event-creation.html</tt>.</p>
+<p>An example of a layout test that follows these guidelines is <code>fast/events/event-creation.html</code>.</p>
<p>A layout test should work both in the browser itself, and in the layout test tool. The layout test tool provides an
additional object on the window object called the layout test controller with some methods that control test output.
-One you should know about is the <tt>layoutTestController.dumpAsText</tt> method. Calling this from JavaScript within a test arranges
+One you should know about is the <code>layoutTestController.dumpAsText</code> method. Calling this from JavaScript within a test arranges
for the output to be written out as plain text rather than as a render tree dump.
This is useful for tests that are testing something other than layout. The event creation test mentioned above is a good example of
how to do this and when it makes sense.</p>
<p>Some tests require pixel-level comparisons. For these tests, you must generate expected output for a specific
machine type, operating system, and color profile. When you add such a test, you can generate new expected output
-automatically using the <tt>run-webkit-tests --pixel</tt> command. This will automatically
+automatically using the <code>run-webkit-tests --pixel</code> command. This will automatically
configure the color profile, and place the resulting rendered image (and checksum) in the appropriate platform
directory for checkin.</p>
git://git.webkit.org / WebKit-https.git / commitdiff