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.

Accepting bug. Marking M11.

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.

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.

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