"ASSERTION: We expect at most one direct child frame" with <input type="number">

RESOLVED FIXED in mozilla29

Status

()

Core
Layout: Form Controls
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: jwatt)

Tracking

({assertion, testcase})

Trunk
mozilla29
x86_64
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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
(Reporter)

Comment 1

4 years ago
Created attachment 8347044 [details]
stack
Created attachment 8360325 [details] [diff] [review]
patch
Attachment #8360325 - Flags: review?(dholbert)
(Assignee)

Updated

4 years ago
Assignee: nobody → jwatt
Status: NEW → ASSIGNED
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.)
Attachment #8360325 - Flags: review?(dholbert) → review+
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. ;)
(Assignee)

Updated

4 years ago
Blocks: 344616
https://hg.mozilla.org/integration/mozilla-inbound/rev/192c2dddd68f
https://hg.mozilla.org/mozilla-central/rev/192c2dddd68f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29

Comment 11

4 years ago
https://hg.mozilla.org/mozilla-central/diff/192c2dddd68f/layout/forms/crashtests/949891.xhtml
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.