237343 - Text not redrawn when uncovered by horizontal scrolling

Status: RESOLVED FIXED

(Core :: Web Painting, defect, P2)

Description

[Stephen Moehle]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040312
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040312

At the above URL, the text on the right edge of the center column is not redrawn
properly when the window is horizontally scrolled right and the text is unconvered.

The problem first appeared in the 2004-03-08-08 Linux nightly build.  The
2004-03-07-08 build is OK.

I do not have reduced test case as my attempts to make one did not exhibit the
problem.

Reproducible: Always
Steps to Reproduce:
1. Go to the URL.
2. Make the browser window about 350 pixels wide so that the text on right edge
of the center column is not visible.
3. Scroll right until the text is uncovered.

Actual Results:  
The text is not completely redrawn, and parts are missing.

Expected Results:  
Redraw the uncovered text.

Selecting the affected area with the mouse or covering it with another window,
etc. will cause the text to be properly redrawn.

Comment 1

[Stephen Moehle]

Attachment: Testcase showing problem

The key to the bug is the "text-align:justify;" paragraph style.  Without it,
there is no problem.  Make the browser window narrow enough to show the
horizontal scroll bar, scroll right, and the text on the right edge will not be
redrawn properly.

Comment 2

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

Something to do with line->CombinedArea not being adjusted for justified lines,
I'll bet.

Comment 3

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

Attachment: further reduced testcase

You don't need the table to show this bug.

Comment 4

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

... and you don't need scrolling either. Just load the testcase. Mouse over the
last word on each line. you'll notice that the cursor sometimes changes from the
I-beam to an arrow even though you're still over text. This is because we've
decided your cursor is outside the line, even though it isn't.

Comment 5

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

Attachment: fix

The problem is that when ApplyFrameJustification widens the frame and the
pfd->mBounds, it neglects to also update pfd->mCombinedArea. So do that.

Comment 6

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

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

another simple layout fix.

This bug has existed forever, but got exposed when we started using the line
combinedAreas more.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

It's worth commenting that this is safe because mCombinedArea is recomputed for
everything other than text frames in nsLineLayout::RelativePositionFrames. 
Otherwise this wouldn't be sufficient if a relatively positioned image were
moved relative to its parent by justification.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

s/everything other than text frames/everything other than leaf frames/

Comment 9

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

Note to choffman/drivers: the risk of regression is exceedingly small (adding to
the combinedArea can't do much bad other than slow us down by repainting more)
and I can land this tonight if it's approved :-)

Comment 10

[Brendan Eich [:brendan]]

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

a=[e-mail] for 1.7b, I forgot to note.

/be

Comment 11

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

checked in.

David: thanks for that comment. actually I think there is a nasty bug related to
this: what if the frame that we're widening is relatively positioned and has
absolute children using the 'right' property to offset from the frame's right
edge? I think we'll have to reflow those children again!

Right now, however, you can't see this bug because our handling of 'right' and
'bottom' for absolute children of relative inlines is just totally broken :-)
(bug 224832).