Right now we have code all over the place to push float containing blocks. We should really just do this inside ProcessChildren (and probably inside CreateAnonymousContent).

Untested so far; need to test tables. Also, this has fieldset issues and major XTF issues.

Afri, you know this XTF stuff, right? Could you please look at the XXX comments near the end of the patch and let me know what you think?

(In reply to comment #2) > Afri, you know this XTF stuff, right? Could you please look at the XXX comments > near the end of the patch and let me know what you think? Sorry, I don't really understand the insertionFrame comment either. This is bryner's code (bug#269023).

I asked bryner about this yesterday and he said that checkin was just preserving the existing algorithm as much as it could and that he didn't know why it was that way to start with... And indeed, the code used to just put the kids in the primary frame for the insertion content. This probably crashed if the anon content was an animated image and the insertion content was a table cell, as it happens. That should certainly crash right now, as the code is written.

One other thought I had was that perhaps the processing of anonymous kids should just be done at the end of ProcessChildren so it gets the containing block love, in case the anon kids happen to be floated.

OK, so the following things have improved since the first cut: 1) XTF frame construction went away 2) We fixed bug 85872, which made it easy to make this work because it's OK to pass in the inner frames of table cells and fieldsets, as we do now, to ProcessChildren. I've made sure this passes reftests and doesn't add any crashtest asserts.

+ * @param aFrame the frame to use as the parent frame for the new in-flow + * kids. Note that this need not be its own content insertion frame, When can aFrame not be its own content insertion frame?

Oh, hmm. I thought that could happen with ContentInserted/ContentAppended, but we do make sure to return the insertion frame for those. Given that, I suspect that this is always the content insertion frame. I'm happy to document and assert that.

And this passes crashtest/reftest

Pushed http://hg.mozilla.org/mozilla-central/rev/5d99fcca32ab