484400 - Incorrect float containing block used in ContentRemoved if the frame being removed is positioned

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Boris Zbarsky [:bzbarsky]]

See bug 162063 comment 21 and the testcases for first-letter in that bug.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Timothy, want to take this?

Comment 2

[Timothy Nikkel (:tnikkel)]

Sure.

I assume changing those other fields was accidental? Unless this bug affects Mac System 9.x users much more than everyone else. :)

Comment 3

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Comment 4

[Boris Zbarsky [:bzbarsky]]

Er, yeah.  I have no idea why those other fields changed.  ;)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 411921 [details] [diff] [review]
patch

Make the reference use a <span> around the T and style the <span>, assuming that still passes?  With that, looks great.

Comment 6

[Timothy Nikkel (:tnikkel)]

(In reply to comment #5)
> (From update of attachment 411921 [details] [diff] [review])
> Make the reference use a <span> around the T and style the <span>, assuming
> that still passes?  With that, looks great.

It does on Linux, but fails on Windows and Mac, so I'll leave it without a styled fake first-letter span. We have tests to make sure that we apply first-letter at all, so it should be fine.

Comment 7

[Timothy Nikkel (:tnikkel)]

They fail because they are shifted by about 1 pixel, not because of anything seriously wrong.

Comment 8

[Timothy Nikkel (:tnikkel)]

Attachment: patch v2

I realized that this change could trigger the assertion that "containingBlock == GetFloatContainingBlock(parentFrame)" lower down in ContentRemoved. But there is no reason for that assertion to hold true, so remove it. And I noticed that we create an unused frame construction state, so got rid of that (and the same in CharacterDataChanged).

Comment 9

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/3062cc1a8882