mirror of
https://gitlab.winehq.org/wine/wine-gecko.git
synced 2024-09-13 09:24:08 -07:00
572 lines
26 KiB
Plaintext
572 lines
26 KiB
Plaintext
Layout Engine Visual Tests (reftest)
|
|
L. David Baron <dbaron@dbaron.org>, Mozilla Corporation
|
|
July 19, 2006
|
|
|
|
This code is designed to run tests of Mozilla's layout engine. These
|
|
tests consist of an HTML (or other format) file along with a reference
|
|
in the same format. The tests are run based on a manifest file, and for
|
|
each test, PASS or FAIL is reported, and UNEXPECTED is reported if the
|
|
result (PASS or FAIL) was not the expected result noted in the manifest.
|
|
|
|
Images of the display of both tests are captured, and most test types
|
|
involve comparing these images (e.g., test types == or !=) to determine
|
|
whether the test passed. The captures of the tests are taken in a
|
|
viewport that is 800 pixels wide and 1000 pixels tall, so any content
|
|
outside that area will be ignored (except for any scrollbars that are
|
|
displayed). Ideally, however, tests should be written so that they fit
|
|
within 600x600, since we may in the future want to switch to 600x600 to
|
|
match http://lists.w3.org/Archives/Public/www-style/2012Sep/0562.html .
|
|
|
|
Why this way?
|
|
=============
|
|
|
|
Writing HTML tests where the reference rendering is also in HTML is
|
|
harder than simply writing bits of HTML that can be regression-tested by
|
|
comparing the rendering of an older build to that of a newer build
|
|
(perhaps using stored reference images from the older build). However,
|
|
comparing across time has major disadvantages:
|
|
|
|
* Comparisons across time either require two runs for every test, or
|
|
they require stored reference images appropriate for the platform and
|
|
configuration (often limiting testing to a very specific
|
|
configuration).
|
|
|
|
* Comparisons across time may fail due to expected changes, for
|
|
example, changes in the default style sheet for HTML, changes in the
|
|
appearance of form controls, or changes in default preferences like
|
|
default font size or default colors.
|
|
|
|
Using tests for which the pass criteria were explicitly chosen allows
|
|
running tests at any time to see whether they still pass.
|
|
|
|
Manifest Format
|
|
===============
|
|
|
|
The test manifest format is a plain text file. A line starting with a
|
|
"#" is a comment. Lines may be commented using whitespace followed by
|
|
a "#" and the comment. Each non-blank line (after removal of comments)
|
|
must be one of the following:
|
|
|
|
1. Inclusion of another manifest
|
|
|
|
<failure-type>* include <relative_path>
|
|
|
|
<failure-type> is the same as listed below for a test item. As for
|
|
test items, multiple failure types listed on the same line are
|
|
combined by using the last matching failure type listed. However,
|
|
the failure type on a manifest is combined with the failure type on
|
|
the test (or on a nested manifest) with the rule that the last in the
|
|
following list wins: fails, random, skip. (In other words, skip
|
|
always wins, and random beats fails.)
|
|
|
|
2. A test item
|
|
|
|
[ <failure-type> | <preference> ]* [<http>] <type> <url> <url_ref>
|
|
|
|
where
|
|
|
|
a. <failure-type> (optional) is one of the following:
|
|
|
|
fails The test passes if the images of the two renderings DO NOT
|
|
meet the conditions specified in the <type>.
|
|
|
|
fails-if(condition) If the condition is met, the test passes if the
|
|
images of the two renderings DO NOT meet the
|
|
conditions of <type>. If the condition is not met,
|
|
the test passes if the conditions of <type> are met.
|
|
|
|
needs-focus The test fails or times out if the reftest window is not
|
|
focused.
|
|
|
|
random The results of the test are random and therefore not to be
|
|
considered in the output.
|
|
|
|
random-if(condition) The results of the test are random if a given
|
|
condition is met.
|
|
|
|
silentfail This test may fail silently, and if that happens it should
|
|
count as if the test passed. This is useful for cases where
|
|
silent failure is the intended behavior (for example, in
|
|
an out of memory situation in JavaScript, we stop running
|
|
the script silently and immediately, in hopes of reclaiming
|
|
enough memory to keep the browser functioning).
|
|
|
|
silentfail-if(condition) This test may fail silently if the condition
|
|
is met.
|
|
|
|
skip This test should not be run. This is useful when a test fails in a
|
|
catastrophic way, such as crashing or hanging the browser. Using
|
|
'skip' is preferred to simply commenting out the test because we
|
|
want to report the test failure at the end of the test run.
|
|
|
|
skip-if(condition) If the condition is met, the test is not run. This is
|
|
useful if, for example, the test crashes only on a
|
|
particular platform (i.e. it allows us to get test
|
|
coverage on the other platforms).
|
|
|
|
slow The test may take a long time to run, so run it if slow tests are
|
|
either enabled or not disabled (test manifest interpreters may
|
|
choose whether or not to run such tests by default).
|
|
|
|
slow-if(condition) If the condition is met, the test is treated as if
|
|
'slow' had been specified. This is useful for tests
|
|
which are slow only on particular platforms (e.g. a
|
|
test which exercised out-of-memory behavior might be
|
|
fast on a 32-bit system but inordinately slow on a
|
|
64-bit system).
|
|
|
|
fuzzy(maxDiff, diffCount)
|
|
This allows a test to pass if the pixel value differences are <=
|
|
maxDiff and the total number of different pixels is <= diffCount.
|
|
It can also be used with '!=' to ensure that the difference is
|
|
greater than maxDiff.
|
|
|
|
fuzzy-if(condition, maxDiff, diffCount)
|
|
If the condition is met, the test is treated as if 'fuzzy' had been
|
|
specified. This is useful if there are differences on particular
|
|
platforms.
|
|
|
|
require-or(cond1&&cond2&&...,fallback)
|
|
Require some particular setup be performed or environmental
|
|
condition(s) made true (eg setting debug mode) before the test
|
|
is run. If any condition is unknown, unimplemented, or fails,
|
|
revert to the fallback failure-type.
|
|
Example: require-or(debugMode,skip)
|
|
|
|
asserts(count)
|
|
Loading the test and reference is known to assert exactly
|
|
count times.
|
|
NOTE: An asserts() notation with a non-zero count or maxCount
|
|
suppresses use of a cached canvas for the test with the
|
|
annotation. However, if later occurrences of the same test
|
|
are not annotated, they will use the cached canvas
|
|
(potentially from the load that asserted). This allows
|
|
repeated use of the same test or reference to be annotated
|
|
correctly (which may be particularly useful when the uses are
|
|
in different subdirectories that can be tested independently),
|
|
but does not force them to be, nor does it force suppression
|
|
of caching for a common reference when it is the test that
|
|
asserts.
|
|
|
|
asserts(minCount-maxCount)
|
|
Loading the test and reference is known to assert between
|
|
minCount and maxCount times, inclusive.
|
|
NOTE: See above regarding canvas caching.
|
|
|
|
asserts-if(condition,count)
|
|
asserts-if(condition,minCount-maxCount)
|
|
Same as above, but only if condition is true.
|
|
|
|
Conditions are JavaScript expressions *without spaces* in them.
|
|
They are evaluated in a sandbox in which a limited set of
|
|
variables are defined. See the BuildConditionSandbox function in
|
|
layout/tools/reftest.js for details.
|
|
|
|
Examples of using conditions:
|
|
fails-if(winWidget) == test reference
|
|
asserts-if(cocoaWidget,2) load crashtest
|
|
|
|
b. <preference> (optional) is a string of the form
|
|
|
|
pref(<name>,<value>)
|
|
test-pref(<name>,<value>)
|
|
ref-pref(<name>,<value>)
|
|
|
|
where <name> is the name of a preference setting, as seen in
|
|
about:config, and <value> is the value to which this preference should
|
|
be set. <value> may be a boolean (true/false), an integer, or a
|
|
quoted string *without spaces*, according to the type of the preference.
|
|
|
|
The preference will be set to the specified value prior to
|
|
rendering the test and/or reference canvases (pref() applies to
|
|
both, test-pref() only to the test, and ref-pref() only to the
|
|
reference), and will be restored afterwards so that following
|
|
tests are not affected. Note that this feature is only useful for
|
|
"live" preferences that take effect immediately, without requiring
|
|
a browser restart.
|
|
|
|
c. <http>, if present, is one of the strings (sans quotes) "HTTP" or
|
|
"HTTP(..)" or "HTTP(../..)" or "HTTP(../../..)", etc. , indicating that
|
|
the test should be run over an HTTP server because it requires certain
|
|
HTTP headers or a particular HTTP status. (Don't use this if your test
|
|
doesn't require this functionality, because it unnecessarily slows down
|
|
the test.)
|
|
|
|
With "HTTP", HTTP tests have the restriction that any resource an HTTP
|
|
test accesses must be accessed using a relative URL, and the test and
|
|
the resource must be within the directory containing the reftest
|
|
manifest that describes the test (or within a descendant directory).
|
|
The variants "HTTP(..)", etc., can be used to relax this restriction by
|
|
allowing resources in the parent directory, etc.
|
|
|
|
To modify the HTTP status or headers of a resource named FOO, create a
|
|
sibling file named FOO^headers^ with the following contents:
|
|
|
|
[<http-status>]
|
|
<http-header>*
|
|
|
|
<http-status> A line of the form "HTTP ###[ <description>]", where
|
|
### indicates the desired HTTP status and <description>
|
|
indicates a desired HTTP status description, if any.
|
|
If this line is omitted, the default is "HTTP 200 OK".
|
|
<http-header> A line in standard HTTP header line format, i.e.
|
|
"Field-Name: field-value". You may not repeat the use
|
|
of a Field-Name and must coalesce such headers together,
|
|
and each header must be specified on a single line, but
|
|
otherwise the format exactly matches that from HTTP
|
|
itself.
|
|
|
|
HTTP tests may also incorporate SJS files. SJS files provide similar
|
|
functionality to CGI scripts, in that the response they produce can be
|
|
dependent on properties of the incoming request. Currently these
|
|
properties are restricted to method type and headers, but eventually
|
|
it should be possible to examine data in the body of the request as
|
|
well when computing the generated response. An SJS file is a JavaScript
|
|
file with a .sjs extension which defines a global |handleRequest|
|
|
function (called every time that file is loaded during reftests) in this
|
|
format:
|
|
|
|
function handleRequest(request, response)
|
|
{
|
|
response.setStatusLine(request.httpVersion, 200, "OK");
|
|
|
|
// You *probably* want this, or else you'll get bitten if you run
|
|
// reftest multiple times with the same profile.
|
|
response.setHeader("Cache-Control", "no-cache");
|
|
|
|
response.write("any ASCII data you want");
|
|
|
|
var outputStream = response.bodyOutputStream;
|
|
// ...anything else you want to do, synchronously...
|
|
}
|
|
|
|
For more details on exactly which functions and properties are available
|
|
on request/response in handleRequest, see the nsIHttpRe(quest|sponse)
|
|
definitions in <netwerk/test/httpserver/nsIHttpServer.idl>.
|
|
|
|
d. <type> is one of the following:
|
|
|
|
== The test passes if the images of the two renderings are the
|
|
SAME.
|
|
!= The test passes if the images of the two renderings are
|
|
DIFFERENT.
|
|
load The test passes unconditionally if the page loads. url_ref
|
|
must be omitted, and the test cannot be marked as fails or
|
|
random. (Used to test for crashes, hangs, assertions, and
|
|
leaks.)
|
|
script The loaded page records the test's pass or failure status
|
|
in a JavaScript data structure accessible through the following
|
|
API.
|
|
|
|
getTestCases() returns an array of test result objects
|
|
representing the results of the tests performed by the page.
|
|
|
|
Each test result object has two methods:
|
|
|
|
testPassed() returns true if the test result object passed,
|
|
otherwise it returns false.
|
|
|
|
testDescription() returns a string describing the test
|
|
result.
|
|
|
|
url_ref must be omitted. The test may be marked as fails or
|
|
random. (Used to test the JavaScript Engine.)
|
|
|
|
e. <url> is either a relative file path or an absolute URL for the
|
|
test page
|
|
|
|
f. <url_ref> is either a relative file path or an absolute URL for
|
|
the reference page
|
|
|
|
The only difference between <url> and <url_ref> is that results of
|
|
the test are reported using <url> only.
|
|
|
|
3. Specification of a url prefix
|
|
|
|
url-prefix <string>
|
|
|
|
<string> will be prepended to relative <url> and <url_ref> for all following
|
|
test items in the manifest.
|
|
|
|
<string> will not be prepended to the relative path when including another
|
|
manifest, e.g. include <relative_path>.
|
|
|
|
<string> will not be prepended to any <url> or <url_ref> matching the pattern
|
|
/^\w+:/. This will prevent the prefix from being applied to any absolute url
|
|
containing a protocol such as data:, about:, or http:.
|
|
|
|
While the typical use of url-prefix is expected to be as the first line of
|
|
a manifest, it is legal to use it anywhere in a manifest. Subsequent uses
|
|
of url-prefix overwrite any existing values.
|
|
|
|
4. Specification of default preferences
|
|
|
|
default-preferences <preference>*
|
|
|
|
where <preference> is defined above.
|
|
|
|
The <preference> settings will be used for all following test items in the
|
|
manifest.
|
|
|
|
If a test item includes its own preference settings, then they will override
|
|
any settings for preferences of the same names that are set using
|
|
default-preferences, just as later items within a line override earlier ones.
|
|
|
|
A default-preferences line with no <preference> settings following it will
|
|
reset the set of default preferences to be empty.
|
|
|
|
As with url-prefix, default-preferences will often be used at the start of a
|
|
manifest file so that it applies to all test items, but it is legal for
|
|
default-preferences to appear anywhere in the manifest. A subsequent
|
|
default-preferences will reset any previous default preference values and
|
|
overwrite them with the specified <preference> values.
|
|
|
|
This test manifest format could be used by other harnesses, such as ones
|
|
that do not depend on XUL, or even ones testing other layout engines.
|
|
|
|
Running Tests
|
|
=============
|
|
|
|
(If you're not using a DEBUG build, first set browser.dom.window.dump.enabled
|
|
to true (in about:config, in the profile you'll be using to run the tests).
|
|
Create the option as a new boolean if it doesn't exist already. If you skip
|
|
this step you won't get any output in the terminal.)
|
|
|
|
At some point in the future there will hopefully be a cleaner way to do
|
|
this. For now, go to your object directory, and run (perhaps using
|
|
MOZ_NO_REMOTE=1 or the -profile <directory> option)
|
|
|
|
./firefox -reftest /path/to/srcdir/mozilla/layout/reftests/reftest.list > reftest.out
|
|
|
|
and then search/grep reftest.out for "UNEXPECTED".
|
|
|
|
There are two scripts provided to convert the reftest.out to HTML.
|
|
clean-reftest-output.pl converts reftest.out into simple HTML, stripping
|
|
lines from the log that aren't relevant. reftest-to-html.pl converts
|
|
the output into html that makes it easier to visually check for
|
|
failures.
|
|
|
|
Testable Areas
|
|
==============
|
|
|
|
This framework is capable of testing many areas of the layout engine.
|
|
It is particularly well-suited to testing dynamic change handling (by
|
|
comparison to the static end-result as a reference) and incremental
|
|
layout (comparison of a script-interrupted layout to one that was not).
|
|
However, it is also possible to write tests for many other things that
|
|
can be described in terms of equivalence, for example:
|
|
|
|
* CSS cascading could be tested by comparing the result of a
|
|
complicated set of style rules that makes a word green to <span
|
|
style="color:green">word</span>.
|
|
|
|
* <canvas> compositing operators could be tested by comparing the
|
|
result of drawing using canvas to a block-level element with the
|
|
desired color as a CSS background-color.
|
|
|
|
* CSS counters could be tested by comparing the text output by counters
|
|
with a page containing the text written out
|
|
|
|
* complex margin collapsing could be tested by comparing the complex
|
|
case to a case where the margin is written out, or where the margin
|
|
space is created by an element with 'height' and transparent
|
|
background
|
|
|
|
When it is not possible to test by equivalence, it may be possible to
|
|
test by non-equivalence. For example, testing justification in cases
|
|
with more than two words, or more than three different words, is
|
|
difficult. However, it is simple to test that justified text is at
|
|
least displayed differently from left-, center-, or right-aligned text.
|
|
|
|
Writing Tests
|
|
=============
|
|
|
|
When writing tests for this framework, it is important for the test to
|
|
depend only on behaviors that are known to be correct and permanent.
|
|
For example, tests should not depend on default font sizes, default
|
|
margins of the body element, the default style sheet used for HTML, the
|
|
default appearance of form controls, or anything else that can be
|
|
avoided.
|
|
|
|
In general, the best way to achieve this is to make the test and the
|
|
reference identical in as many aspects as possible. For example:
|
|
|
|
Good test markup:
|
|
<div style="color:green"><table><tr><td><span>green
|
|
</span></td></tr></table></div>
|
|
|
|
Good reference markup:
|
|
<div><table><tr><td><span style="color:green">green
|
|
</span></td></tr></table></div>
|
|
|
|
BAD reference markup:
|
|
<!-- 3px matches the default cellspacing and cellpadding -->
|
|
<div style="color:green; padding: 3px">green
|
|
</div>
|
|
|
|
BAD test markup:
|
|
<!-- span doesn't change the positioning, so skip it -->
|
|
<div style="color:green"><table><tr><td>green
|
|
</td></tr></table></div>
|
|
|
|
Asynchronous Tests: class="reftest-wait"
|
|
========================================
|
|
|
|
Normally reftest takes a snapshot of the given markup's rendering right
|
|
after the load event fires for content. If your test needs to postpone
|
|
the moment the snapshot is taken, it should make sure a class
|
|
'reftest-wait' is on the root element by the moment the load event
|
|
fires. The easiest way to do this is to put it in the markup, e.g.:
|
|
<html class="reftest-wait">
|
|
|
|
When your test is ready, you should remove this class from the root
|
|
element, for example using this code:
|
|
document.documentElement.className = "";
|
|
|
|
|
|
Note that in layout tests it is often enough to trigger layout using
|
|
document.body.offsetWidth // HTML example
|
|
|
|
When possible, you should use this technique instead of making your
|
|
test async.
|
|
|
|
Invalidation Tests: MozReftestInvalidate Event
|
|
==============================================
|
|
|
|
When a test (or reference) uses reftest-wait, reftest tracks invalidation
|
|
via MozAfterPaint and updates the test image in the same way that
|
|
a regular window would be repainted. Therefore it is possible to test
|
|
invalidation-related bugs by setting up initial content and then
|
|
dynamically modifying it before removing reftest-wait. However, it is
|
|
important to get the timing of these dynamic modifications right so that
|
|
the test doesn't accidentally pass because a full repaint of the window
|
|
was already pending. To help with this, reftest fires one MozReftestInvalidate
|
|
event at the document root element for a reftest-wait test when it is safe to
|
|
make changes that should test invalidation. The event bubbles up to the
|
|
document and window so you can set listeners there too. For example,
|
|
|
|
function doTest() {
|
|
document.body.style.border = "";
|
|
document.documentElement.removeAttribute('class');
|
|
}
|
|
document.addEventListener("MozReftestInvalidate", doTest, false);
|
|
|
|
Painting Tests: class="reftest-no-paint"
|
|
========================================
|
|
|
|
If an element shouldn't be painted, set the class "reftest-no-paint" on it
|
|
when doing an invalidation test. Causing a repaint in your
|
|
MozReftestInvalidate handler (for example, by changing the body's background
|
|
colour) will accurately test whether the element is painted.
|
|
|
|
Snapshot The Whole Window: class="reftest-snapshot-all"
|
|
=======================================================
|
|
|
|
In a reftest-wait test, to disable testing of invalidation and force the final
|
|
snapshot to be taken of the whole window, set the "reftest-snapshot-all"
|
|
class on the root element.
|
|
|
|
Zoom Tests: reftest-zoom="<float>"
|
|
==================================
|
|
|
|
When the root element of a test has a "reftest-zoom" attribute, that zoom
|
|
factor is applied when rendering the test. The reftest document will be
|
|
800 device pixels wide by 1000 device pixels high. The reftest harness assumes
|
|
that the CSS pixel dimensions are 800/zoom and 1000/zoom. For best results
|
|
therefore, choose zoom factors that do not require rounding when we calculate
|
|
the number of appunits per device pixel; i.e. the zoom factor should divide 60,
|
|
so 60/zoom is an integer.
|
|
|
|
Setting Viewport Size: reftest-viewport-w/h="<int>"
|
|
===================================================
|
|
|
|
If either of the "reftest-viewport-w" and "reftest-viewport-h" attributes on
|
|
the root element are non-zero, sets the CSS viewport to the given size in
|
|
CSS pixels. This does not affect the size of the snapshot that is taken.
|
|
|
|
Setting Async Scroll Mode: reftest-async-scroll attribute
|
|
=========================================================
|
|
|
|
If the "reftest-async-scroll" attribute is set on the root element, we try to
|
|
enable async scrolling for the document. This is unsupported in many
|
|
configurations.
|
|
|
|
Setting Displayport Dimensions: reftest-displayport-x/y/w/h="<int>"
|
|
===================================================================
|
|
|
|
If any of the "reftest-displayport-x", "reftest-displayport-y",
|
|
"reftest-displayport-w" and "reftest-displayport-h" attributes on the root
|
|
element are nonzero, sets the displayport dimensions to the given bounds in
|
|
CSS pixels. This does not affect the size of the snapshot that is taken.
|
|
|
|
When the "reftest-async-scroll" attribute is set on the root element, *all*
|
|
elements in the document are checked for "reftest-displayport-x/y/w/h" and have
|
|
displayports set on them when those attributes are present.
|
|
|
|
Testing Async Scrolling: reftest-async-scroll-x/y="<int>"
|
|
=========================================================
|
|
|
|
When the "reftest-async-scroll" attribute is set on the root element, for any
|
|
element where either the "reftest-async-scroll-x" or "reftest-async-scroll-y
|
|
attributes are nonzero, at the end of the test take the snapshot with the given
|
|
offset (in CSS pixels) added to the async scroll offset.
|
|
|
|
Printing Tests: class="reftest-print"
|
|
=====================================
|
|
|
|
Now that the patch for bug 374050 has landed
|
|
(https://bugzilla.mozilla.org/show_bug.cgi?id=374050), it is possible to
|
|
create reftests that run in a paginated context.
|
|
|
|
The page size used is 5in wide and 3in tall (with the default half-inch
|
|
margins). This is to allow tests to have less text and to make the
|
|
entire test fit on the screen.
|
|
|
|
There is a layout/reftests/printing directory for printing reftests; however,
|
|
there is nothing special about this directory. You can put printing reftests
|
|
anywhere that is appropriate.
|
|
|
|
The suggested first lines for any printing test is
|
|
<!DOCTYPE html><html class="reftest-print">
|
|
<style>html{font-size:12pt}</style>
|
|
|
|
The reftest-print class on the root element triggers the reftest to
|
|
switch into page mode. Fixing the font size is suggested, although not
|
|
required, because the pages are a fixed size in inches. The switch to page mode
|
|
happens on load if the reftest-wait class is not present; otherwise it happens
|
|
immediately after firing the MozReftestInvalidate event.
|
|
|
|
The underlying layout support for this mode isn't really complete; it
|
|
doesn't use exactly the same codepath as real print preview/print. In
|
|
particular, scripting and frames are likely to cause problems; it is untested,
|
|
though. That said, it should be sufficient for testing layout issues related
|
|
to pagination.
|
|
|
|
Plugin and IPC Process Crash Tests: class="reftest-expect-process-crash"
|
|
========================================================================
|
|
|
|
If you are running a test that causes an out-of-process plugin or IPC process
|
|
under Electrolysis to crash as part of a reftest, this will cause process
|
|
crash minidump files to be left in the profile directory. The test
|
|
infrastructure that runs the reftests will notice these minidump files and
|
|
dump out information from them, and these additional error messages in the logs
|
|
can end up erroneously being associated with other errors from the reftest run.
|
|
They are also confusing, since the appearance of "PROCESS-CRASH" messages in
|
|
the test run output can seem like a real problem, when in fact it is the
|
|
expected behavior.
|
|
|
|
To indicate to the reftest framework that a test is expecting a plugin or
|
|
IPC process crash, have the test include "reftest-expect-process-crash" as
|
|
one of the root element's classes by the time the test has finished. This will
|
|
cause any minidump files that are generated while running the test to be removed
|
|
and they won't cause any error messages in the test run output.
|
|
|
|
Skip Forcing A Content Process Layer-Tree Update: reftest-no-sync-layers attribute
|
|
==================================================================================
|
|
|
|
Normally when an multi-process reftest test ends, we force the content process
|
|
to push a layer-tree update to the compositor before taking the snapshot.
|
|
Setting the "reftest-no-sync-layers" attribute on the root element skips this
|
|
step, enabling testing that layer-tree updates are being correctly generated.
|
|
However the test must manually wait for a MozAfterPaint event before ending.
|