We're doing an incremental reflow targeted at a nested inline frame. However, the line prior to the line containing the target frame will have been marked dirty. So we reflow that line, which in bug 91423 causes the continuations containing the target frame to be destroyed.
Note, however, that the inline frames along the reflow path are not dirty. So what rbs suggests in bug 116230 won't work ``out of the box''. It might work if we tried to do something when we detect that we're processing a frame that's along the incremental reflow's path. For example, we could mark all of the continuations dirty at that point.
But even something like that would probably have little effect
since we'd need the reflow reason to be modified to
eReflowReason_Dirty in order to properly notice those
frames. Well, I might take that back, given the else
case in nsLineLayout::ReflowLine.
Argh! But of course that won't work, because we'll never
stumble into the case where
*aNextRCFrame == aFrame, because we nuke the
continuation!
Okay, I think I can
get around
rbs's
objection
by simply moving the fixup code out of ReflowLine and
up into PrepareChildIncrementalReflow, where it
probably ought to have been in the first place.
Spent some time looking at some floater fun, bug 99461. More fun buster droppings here.
Note sure what to do about bug 99461: deferring to dbaron, and possibly to attinasi (who has a lot of floater bugs on his plate, I guess).
Poked at
bug 41521
for a bit to see if I could figure out how to fix restyles across
block-in-inline hierarchies. Figured out some of the problem, but
the magic involved in recomputing style contexts left me
baffled. FUTURE for now, unless there's some reason it
ought to be more pressing. I really ought to look at why the
block-in-inline stuff doesn't work in XHTML...
Started looking at bug 91185, minimizing to a test case at this point.
Tried to answer dbaron's
question
about float-in-a-float for bug 52242. Turns out this behavior hasn't
been specified yet; regardless, we appear to do something completely
irrational. Quick look at another
purported float bug:
looked bad, but I'm not sure it's related to floats. Spent a bit of
time trying to backport the fix for
bug 91423
/
bug 116230
to the mozilla-0.9.4 branch. Helped bryner with some
XBL form stuff (well, not really -- banged around a bit
though). Helped suresh with some buddy list stuff; have him an
alternative
to the route he was pursuing to get the offline buddies
working. Needed a bit o' help from bryner to get the
<tree> syntax right.
Finished the back-port for bugs 91423 and 116230. Spent the rest of the day learning more about block and line layout while digging in to bug 52242.
dbaron's first-line assessment of this bug is, of course, right:
we're using the mOverflowArea of the floated element as
its combined area. Presumably, this area isn't including the bottom
margin, so the table cell isn't expanded vertically.
(As an aside, a cheap and trashy ``fix'' for the test case would be to properly apply the height of the max element size, which we don't appear to do right now. That's probably worthy of another bug.)
So why isn't the overflow area of the floater including its bottom
(?) margin? Well, in nsBlockFrame::ComputeFinalSize, we
add up the combined area of the lines contained in the
float. And it appears that the combined area of the only line in the
float includes the top (?) margin, but not the bottom margin. So,
how do we compute the line's combined area?
The line's combined area is computed in
nsBlockFrame::PlaceLine, which calls
nsLineLayout::RelativePositionFrames.
RelativePositionFrames recurses through the
PerFrameData for each frame on the line, and
accumulates each frame's rectangle. This is all zero in the test
case, because there's nothing but a floater on the line.
The float's area is added later in
nsBlockFrame::PlaceLine, where we take the line's
combined area and union it with
nsBlockReflowState::mFloaterCombinedArea. How is
this maintained, you ask?
nsBlockReflowState::FlowAndPlaceFloater retrieves it
into the nsFloaterCache object's
mCombinedArea field when it calls
nsBlockFrame::ReflowFloater, and then accumulates it
with the its own mFloaterCombinedArea field.
ReflowFloater retrieves sets the combined area by
simply assigning it from the nsHTMLReflowMetrics
object's mOverflowArea. At this point, it is exactly
the size of the image.
Okay, so that all seems fine. It looks like the problem starts when
nsBlockReflowState::FlowAndPlaceFloater also retrieves
margin information into the nsFloaterCache object's
mMargins slot. But this appears to include all the
proper margin information.
This is all stored joyfully in the floater cache, and is correct at this point as far as I can tell. At this point, the floater's combined area is the size of the image, and it is left- and top-indented to account for the margins.
So the next place I need to look is
nsLineLayout::UpdateBand, which is where we go right
after FlowAndPlaceFloater. More soon.
Thought about this a little more in the car on the way home last
night and realized that we are maintaining all of the
information we need already: in the space manager. Proposed a
sloppy patch
to incorporate the space manager's y-most value into the mix for an
auto-height block. Hacked and slashed through a
problem
with asynchronous updates in the content model builder. Should be
fixed and ready for consumption by suresh.
Implemented
parseType support in the RDF content sink so that we
can read and write integer and date literals.
After applying the patch for bug 118863, suresh is still having problems with the AIM datasource. Need to look at that tomorrow.
Landed the fix for
bug 91423
an its ilk on the mozilla-0.9.4 branch. Rewrote the
parseType patch to use nc:parseType for
Integer and Date to
appease tingley
(he's right, after all, you lazy bum). Found still another
incorrect use of IsElementContainedBy, which was
causing the straggling problem that was suresh was seeing in
bug 118863.
Knock on wood, it should be fixed now.
Moved all untargeted bugs to `Future'. Landed fixes for bug 52242, bug 118865 (which should also fix bug 33197), bug 115926, and bug 109200.
Dug into bug 119311: bryner wanted some help figuring out why the block frame was force-invalidating the entire XBL select control. As far as I could tell, it looks like a typical kipp crawl-walk-run implementation that just needed some juice. Specifically, a ``force invalidate'' would invalidate the union of the old and new line's area, instead of just invalidating any left-over area if the new area shrank.
Tracked down a fix for
bug 86276,
where we weren't properly handling block-in-inline situations in
non-HTML XML. Turns out that we weren't applying the
:-moz-anonymous-block pseudo-class to all namespaces;
just HTML.
Spent some time looking into bug 119504, a problem with the insertion sort (maybe) in rdfliner. I'm pretty sure that things are correct as they are now, but I need to do a bit of legwork to prove it to myself.
Ack. So it turns out that there is a bug in that sorting code, but even with it fixed, folder renaming causes the rdfliner to go bat-shit. I think it's because of the ``one resource per rdfliner'' problem (which isn't on file, so I filed bug 120229 to cover it.)
So after some more digging, it turns out that the scrambled-up insertion had nothing to do with duplicate resources. Instead, it was caused by my badly botched insertion implementation which failed to account for open subtrees during asynchronous updates. I stole bug 119504 from naving: my fault, all my fault.
Came up with a good patch for bug 119504 that really fixes the bug, and then came up with an even better one that also fixes bug 96748, too. Actually, these were pretty much the same bug.
Continued to investigate invalidation for
bug 119311.
My assumption about inline frames doing any invalidation was
completely wrong: the block frame handles all invalidation during
incremental reflow. I did notice an oddity in
nsTextFrame, however. Specifically, the code that's
there for incremental reflow doesn't seem to take into account the
text frame's x and y coordinate when
constructing the dirty rect. Also, this code tends to have no
effect during the initial reflow. I need to do a bit of archaeology
there to untangle two or three layers of hacks that have been piled
on there.
Took a quick look at a purported
RDF crasher:
worked fine for me once I re-wrote to use the latest, greatest
syntax. Spent the rest of the day banging around another hack for
bug 119311.
Was able to get rid of the nsTextFrame hack; had
nsBox target incremental reflows at itself instead of
delegating to the block. Only problem is that the test case for
bug 2222
is now busted. Helped jag figure out how to do the accesskey
implementation for HTML labels and XUL.
Implemented a fix for
bug 116328,
which makes the XUL outliner builder grok nsIRDFBlob
literals.
Posted
a proposal that could get rid of the magic sorting crap that the
XUL sort service requires. Collapsed mLazyState and
mAttributes in the nsXULElement::Slots
structure to
save a word
there. Spent some time looking into
moving the resource map out of the content model,
but I'm gonna punt on that for now: it'd just be to big of a change
to make before leaving for two months (and I'm not sure it'd be
that much of a win, anyway). Worked up a patch for
bug 86755,
wherein an <outliner> inside an XBL file was not
getting a database attribute early enough.
Couple super-reviews. Dug in to
bug 99691
(remove nsSpaceManager construction code from
nsBoxToBlockAdaptor), and figured out why we
were creating block frames without space managers: XUL
<label> and <description>
frames. Since they were just picking up the default block style,
they didn't get a space manager. Coughed up a fix to hard-code
these to generate area frames.
Landed bug fixes for 86755, 99691, 105068, 108259, 116328, and 121712.
Took a quick look at some pldhash warnings that fire
during startup. Looks like the
nsScriptNameSpaceManager::mGlobalNames and
nsHTMLDocument::mIdAndNameHashTable tables may favor
chaining over double-hashing. I'll bug jst about that.
Fixed an
assertion
that timeless found. Took a bit longer than it should've because I
didn't realize he was doing an optimization at the same
time. Bungled my checking for
bug 108259
yesterday, ended up causing a
blocker
this morning: oops. Banged on
bug 119311
some more, but I just don't see a way (within the current design)
to get us to not invalidate the entire line containing the
<select>. Gave up, future'd. Took a quick look at
bug 102860,
a problem with dynamic insertion of relatively-positioned
frames. Easy fix. Botched an easy case in my for
bug 99691:
this led to a nasty regression,
bug 121860.
I think I've got a fix there.
Poked at inline-margins a bit in
bug 46918.
Think I fixed margin-left for left-to-right text, at
least.
Fixed a latent bug in the RDF service that was exposed by recent URI parsing changes. Landed fixes for bug 121860 and bug 102860. Wrote up an example for doing `wrapper' datasources in JS. Spent some more time looking in to bug 46918, mostly trying to figure out how to get ``margin start'' to work for right-to-left frames.
I think I've come up with a fix for the inline margin bugs
46918
and
3490.
Banged around another bidi inline bug
(bug 121633)
in hopes that it might be an incremental fix on top, but it turned
out to be a bit more complicated. Looked at yet another
crasher
that's fallen out from the
box-to-block adaptor surgery:
finally decided to punt and hack nsBoxToBlockAdaptor
to set the NS_BLOCK_SPACE_MGR bit itself. Started
looking at
bug 52916,
which is another one Hixie wants for 1.0. Learned about the
Y-combinator.
Talked with people about footprint and allocators most of the day. Landed fixes for the two inline margin bugs, 46918 and 3490. Worked out a possible fix for another Hixie bug, but this one I'm not real sure about. Couple code reviews.