Meetings. Tough-love triage on bug list.

Coughed up a DOM-only testcase for bug 78290, which had been blaming RDF for a generic dynamic menu problem. Took a quick look at 70830, but am not exactly sure what the problem is. Checked in fixes for 78013 and 78055. Spent some time fiddling around with a problem with -moz-pre-wrap that shanjian is working on. More ruthless bug triage.

Thought a little bit about 48138: a floater inside a table cell doesn't properly impact the in-flow lines. I don't think that there is a sane way to correctly compute deltaY when BRS_COMPUTEMAXWIDTH is set. (That flag causes us to reflow the inline frames at an unconstrained width, and then flow them again at the computed width. Reflowing at an unconstrained width clobbers all the line boxes, and so when we ReflowDirtyLines(), each line box thinks its old height was zero.)

Worked up a monster patch for RDF/XML serialization, bug 38516. Also factored the serializer and the parser out of nsRDFXMLDataSource and into there own, component-manager addressable objects. This'll allow people to parse RDF/XML into a datasource from an arbitrary string, or to serialize RDF/XML out of a datasource to an aribtrary nsIOutputStream. The RDF/XML that we generated is also legible (finally).

Broke out patches for saving reflow state into bug 78911, and am hoping to get some feedback on that.

Got off the pot and put together rdfliner docs, and discovered two bugs along the way (78940 and 78941).

Checked in fixes for 78940 and 78941, as well as 77209, which was removing a bunch of duplicate symbols from imagelib.

Did a quick n' dirty profile of new window opening: 8% of the time goes to recompiling JS for XBL event handlers n' stuff. Talked to hyatt: he's already got a bug and is deep in style sharing stuff. But the real reason that I looked into it was to see if brutally sharing attributes would do anything. At this point, it looks like it's only a 1-2% speedup, because people seem to have gotten rid of about half the setAttribute calls since I last looked.

Spent a few hours getting the regressions tests working again; jud checked in a bit o' bad juju there.

Finished regression test stuff; got everything together over on Linux, too. rbs reminded me that brade had put a nice, succinct test case for the regression that my changes in bug 43914 had caused. Looked into it some more today. What's happening is that when nsBlockFrame::ReflowDirtyLines() calls FindLineFor(), we're dirtying only the first frame in what is potentially a string of continuation frames. Specifically, we start with a situation like this (without the whitespace):

That yields the following frame model:

When we insert new frames into the <b> span, the frame for the span marks itself dirty and calls the containing block frame's ReflowDirtyChild() method. nsBlockFrame::ReflowDirtyChild() uses FindLineFor() to find the line containing the <b> span's primary frame, and marks only that line dirty. So one way to look at the problem is that we need to mark the lines containing the continuing frames dirty, too.

Spent some more time looking at floaters in bug 59200, and found two things that look like they're wrong with our current implementation. First, as we discover that a floater won't fit on the line, we push it down to the next place where there's available space. That's okay, but we don't reflow the floater in the new space, which leaves us flowing the floater at the width where it wouldn't fit. I've worked up a partial fix for that in nsBlockReflowState. The other thing that we don't seem to get right is obeying the floater's maxElementSize.