257430 - regression: can't click button on page

Status: VERIFIED FIXED

(Core :: Web Painting, defect, P2)

Description

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

The offical 8/24 nightly WFM, official 8/26 nightly doesn't work.  08/25
wouldn't run so I couldn't test it.  I can't click any of the buttons in the
second row.

Comment 1

[jon rekai]

The align attribute on the image inputs is involved.

Comment 2

[Mats Palmgren (inactive)]

Regression window: 2004-08-25-05 -- 2004-08-26-05
After backing out bug 133165 it does not occur (I got one reject I had to fix
manually, so I'm only 99% sure).

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase

Comment 4

[Boris Zbarsky [:bzbarsky]]

The change to nsIFrame::FinishAndStoreOverflow is rather suspect (or rather,
it's the only change that should affect anything but painting).  Does reverting
just that hunk (and mucking with it to get it to compile) help?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This bug is intriguing. Giving the floated input control the focus reflows it
incrementally, and that results in an incorrect computed overflow area for the
block (nearly empty). I think we just revealed a bug in incremental reflow.

Comment 6

[Mats Palmgren (inactive)]

Attachment: Some code...

FWIW, this fixes the problem in a current trunk tree.
(and the focus outline is all around the image).

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That shouldn't be necessary because frames are supposed to already include their
bounds in the reflow state's mOverflowArea. The fact that this isn't happening
is the problem...

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: fix

Image frames need to set their overflow area to their bounds.

Also adds an assertion to FinishAndStoreOverflow to catch any more violations.

That caught nsTableRowFrame seeming to change a cell's width and height without
adjusting its overflow area. I don't know how this can be correct, but I add a
fix there to make sure the overflow area includes the new cell bounds.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 157578 [details] [diff] [review]
fix

making sure that frames compute an overflow area that includes their bounds

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

checked in.