Herein lie fun HTML and XUL test cases that illustrate bugs and stuff. It's not quite as clever or well organized as dbaron's CSS playground or Hixie's tests, but it's a start. And relevant to my little corner of Mozilla fun.
While working on the reflow tree, dbaron pointed out that there could be cases where an incremental reflow targeted at a container could mask incremental reflows targeted at one of the container's children, or might not properly be propagated to the container's children.
<div> could potentially
mask an incremental style-changed reflow targeted at a nested
frame.
<div> might not
properly be propagated to its children.
This revision of the work actually has the latter problem.
While working on
eliminating nsBlockFrame::RememberFloaterDamage,
I thought it would be good to come up with a couple of test cases
that stress incremental floater reflow. These all trigger
incremental style-changed reflows, and are self-animating:
These trigger incremental dirty reflows when you click on the document body:
There's also:
While working on the incremental reflow tree, I broke some table incremental reflow. This is a test that triggers two dirty reflows, targeted at two different rows, when you click on the page body somewhere. (It's interesting in the context of the reflow tree, because the reflow tree coalesces them, and if you've botched the iteration, you'll drop one on the floor.)
Here are some test cases for <caption> elements,
which I also
broke
with the reflow tree landing.
More
incremental reflow tree
fun.
This
is a test case that modifies the contents of the combobox
dynamically: I created it to see just exactly what the special-case
code for handling the drop-down frame in
nsComboboxControlFrame was doing. Apparently, it isn't
doing much of anything: in theory, comboboxes shouldn't update with
the incremental reflow tree changes; however, they seem to work
just fine.
rods gave me three other test cases to try that are similar:
This is a test case for a
remote datasource bug
(which, unfortunately, I couldn't reproduce). Both the XUL and the
RDF are loaded via the http: protocol.
This is a test case for a bug that causes DOM properties to be inaccessible from a signed script. There is a follow-on bug that deals with the security manager getting confused by an XML document being created from script: specifically, it doesn't think that the new document has a cert that is compatible with the original script's principal.
You may need to install this cert and give it “software signing” privileges to actually use the test cases above.