Created attachment 8347042 [details] testcase ###!!! ASSERTION: We expect at most one direct child frame: '!mFrames.FirstChild() || !mFrames.FirstChild()->GetNextSibling()', file layout/forms/nsNumberControlFrame.cpp, line 79
Created attachment 8360325 [details] [diff] [review] patch
Comment on attachment 8360325 [details] [diff] [review] patch r=me, with one nit: >+++ b/layout/forms/crashtests/crashtests.list >@@ -48,8 +48,10 @@ skip-if(B2G) load 498698-1.html # bug 83 > asserts(1) load 578604-1.html # bug 584564 > asserts(4-7) load 590302-1.xhtml # bug 584564 > load 626014.xhtml > load 639733.xhtml > asserts(0-1) load 669767.html > load 682684.xhtml > load 865602.html > load 944198.html >+load 949891.xhtml >+ nit: you're adding a fully blank line (on top of the customary terminating newline) at the end of this manifest file. Probably best not to do that. (though not a huge deal; whoever appends to this file next will presumably just fill that blank line in.)
Not having a trailing blank line really irks me. When using vim I then have to type: Shift-G Shift-$ i Right-arrow Enter before I can append a line instead of just: Shift-G i So I don't agree with this convention. :)
Ah, ok -- I assumed you'd just left it there by accident. r=me either way
(Side note: emacs actually renders the conventional trailing newline -- and so, its own "seek-to-end-of-file" command (Alt-Shift->) seeks to the cursor-position following that newline, right where you should start typing to append the new test entry. If we followed your proposed fully-blank-line-at-the-end convention, emacs users would have to take the extra step of hitting "up-arrow" before they could start appending a line. Not a huge amount of work, sure :) but just pointing out that there's some sense to the existing convention, and changing it to save steps for you would add steps for other folks.)
Also, googling "vi commands new line" turned up the "o" command ("Open a new line after current line"), which I think saves you all of the steps in your process at the beginning of comment 4.
Ah, nice, thanks! I still think it's nicer to have a blank line ready at the end, but I can get over that a lot more easily than getting over an extra three awkward keystrokes. ;)