13440 - Repaint problems when typing at the end of a document.

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[kinmoz]

1. Load or create a file in the editor that fills the entire edit area with
text, from top to bottom.

2. Place the cursor at the very end of the document.

3 Hit the return key.

4. Now type something.

Repeat steps 3 and 4 so that the contents of the edit area begins to scroll
upwards. Notice that some of the contents in the edit area begins to overlap or
paint over each other?

This problem does not seem to happen on Linux, but I am able to reproduce it on
Mac and Windows.

Comment 1

[kinmoz]

Accepting bug. Marking M11.

Comment 2

[kinmoz]

Here's the short description of what I think is happening:

As I type at the bottom of the document, in the manner described in the
bug report, the document is incrementally reflowed and the region
containing the character I just typed, in this case the last line of the
document, is marked as damaged.

Then nsScrollFrame::DidReflow() calls
nsScrollingView::ComputeScrollOffsets() to adjust the scrollbars to
account for the change in the document's size.

The problem here is that a call to
nsScrollingView::ComputeScrollOffsets() can result in a change to the
view's scroll offsets, without scrolling anything on the screen first.

When it comes time to paint, the damaged/clipping regions are wrong
because the document has shifted.

I have a temporary fix in place that involves ComputeScrollOffsets()
calling UpdateView() when it changes the view's scroll offsets:

    if ((dx != 0) || (dy != 0))
    {
      if (aAdjustWidgets)
        AdjustChildWidgets(this, scrolledView, 0, 0, scale);

      mViewManager->UpdateView(scrolledView, nsnull,
NS_VMREFRESH_NO_SYNC);
    }

This seems to fix the problem. Is this the right thing to do? If this is
the right thing to do, I should probably call update view with the
proper damage rects instead of updating the entire view right, or is it
not worth the effort?

I also noticed that ComputeScrollOffsets() always changes the scroll
offsets if the size of the document grows:


    mOffsetY =
NSIntPixelsToTwips(NSTwipsToIntPixels(nscoord(((float)oldpos * mSizeY) /
oldsizey), scale), p2t);

    ...

    mOffsetX =
NSIntPixelsToTwips(NSTwipsToIntPixels(nscoord(((float)oldpos * mSizeX) /
oldsizex), scale), p2t);

Should we be doing that? That doesn't seem right to me.

Comment 3

[kinmoz]

Spoke with Troy about the fix described above. We agreed that I wouldn't check
in the code that updates the entire screen.

For now, I checked in a change that prevents ComputScrollOffsets() from
adjusting the view's scroll offsets just because the view size grew. This fixes
the problem mentioned in this bug, but there are still repaint problems that
can occur like when we delete from the middle to the end of the document. I will
file another bug regarding this and a description of how we think it should be
fixed.

Fix checked into mozilla/view/src/nsScrollingView.cpp revision 3.111:

  - modified nsScrollingView::ComputeScrollOffsets()
    so that it doesn't change the scrolled offsets
    just because the document size changed.

Comment 4

[sujay]

verified in 9/16 build...the cursor is giant though...filing a separate
bug..