657461 - incorrect caret drawn in google calendar with zooming

Status: NEW

(Core :: DOM: Editor, defect)

Description

[Timothy Nikkel (:tnikkel)]

If I click in an empty space in a google calendar to create a new event the caret in the box where the event name is to go is sometimes only drawn partially. It depends on the zoom level (try zooming in a few times) and the location you click in the calendar (try clicking in a bunch of different places).

Regression range from nightlies
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7d90da136b2c&tochange=fe3f7889918b

Maybe bug 644428 or bug 646382.

Comment 1

[Timothy Nikkel (:tnikkel)]

a7056f19b2aa is the first bad changeset, so bug 646382.

Comment 2

[(no longer active)]

OK, here's what's happening.  In the testcase for bug 646382, the BR frame is put on the baseline because we're not in the standards compliance mode, so the value that we return from GetBaseline ends up being correct.  In the testcase here, however, the document is in standards compliance mode, and the BR frame ends up at the top of the line, so the baseline value returned (0) is not correct, which causes us to invalidate the wrong line.

The fix is to change the behavior based on the BR_USING_CENTERED_FONT_BASELINE flag.  It's tricky though, since by the time that the first GetBaseline call is made to get the caret rect, the BR frame has not been reflowed yet, so that bit would always be unset.  I looked into copying the logic of BRFrame::Reflow which determines when to set that bit, but that is also hard, since we don't have an nsLineLayout object around...  I'm not sure what a solution would look like.

Comment 3

[(no longer active)]

Attachment: WIP

The WIP patch that I have so far...