15384 - Drag scrolling results in corrupted page content

Status: VERIFIED FIXED

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

Description

[Eli Goldberg]

* TITLE/SUMMARY
[PP] Drag scrolling results in corrupted page content

* STEPS TO REPRODUCE
0) Launch Apprunner. View any page. (I used www.netscape.com.)
1) Drag-scroll the page upwards and downward (e.g. resize the window so that
vertical scroll bars appear. Then, holding the mouse button down, drag downwards
and upwards so that the page scrolls)

* RESULT
 - What happened

Drag scrolling (yippee!) occurs correctly. However, substantial page corruption
occurs. Will enclose a screen shot or two, but highlights include:
	* repeated page content
	* truncated tops or bottoms of text
	* text selection of only the top or bottom half of text (after it scrolls)

 - What was expected

No corruption from scrolling.

* REGRESSION

 - Occurs On
        Mac OS Apprunner (1999 10/01 08:00 optimized build)
        Linux Apprunner (1999 10/01 08:00)

 - Doesn't Occur On
        Win32 Apprunner (1999 10/01 08:00 optimized build [NT 4, Service Pack 5])


* CONFIGURATIONS TESTED

- [Mac] Beige Power Mac G3 (266 MHz PowerPC 750), 96 MB RAM (VM on; 1 MB of VM
used), 1024x768 (Thousands of Colors), Mac OS 8.6

- [Win32] Vectra VL (233 MHz P2), 96 MB RAM, 800x600 (True Color), NT 4.0 SP5.

- [Linux] Vectra VL (266 MHz P2), 96 MB RAM. Red Hat Linux 6.0 (GNOME).

Comment 1

[Eli Goldberg]

[QA assigning to self.]

Comment 2

[Eli Goldberg]

Attachment: JPEG Example of corruption (Mac OS)

Comment 3

[Eli Goldberg]

[Note to self: please double-check that bug #5495 is also fixed when verifying
this bug.]

Comment 4

[kinmoz]

I'll take this one since it's a redraw problem.

Comment 5

[kinmoz]

Accepting bug.

Comment 6

[kinmoz]

I'm going to need help from one of our resident Mac Editor folks, either
[e-mail] or [e-mail], on this one. Cc'd them.

Comment 7

[kinmoz]

I was told that [e-mail] was looking into scrolling problems this
week. Assigning bug to [e-mail].

Comment 8

[Patrick C. Beard]

This will go into the mix. This is probably a duplicate of another bug I already
have. It is at least related to bug #15952.

Comment 9

[chris hofmann]

sounds like we should look at this early in m12.
sounds ugly.  does it happen every time?

Comment 10

[Eli Goldberg]

chofmann, yes, this is 100% reproducible through drag-scrolling.

Please note that using the 1999110808 *Linux* build, a more subdued variation of
this behavior occurs --- specifically, while the selected text remains
uncorrupted, the selection itself becomes corrupted, in that the right-hand
portion of the selection only covers the bottom half of the text.

Comment 11

[leger]

Is the workround to resize the window?  Can you use scroll bar?  Scroll arrow?
Putting on PDT-.  Please note workaround at:
http://bugzilla.mozilla.org/show_bug.cgi?id=17788

If no workaround, remove PDT- and we will review bug again.

Comment 12

[Eli Goldberg]

All of those work.

I fear I fell short of my normal bug writing standards here, and neglected to
specifically note that one must specifically drag page _content_ in order for
this corruption to occur. Thanks for pointing that out.

Comment 13

[Patrick C. Beard]

Moving all to M14

Comment 14

[Eli Goldberg]

[marking as beta1 for PDT radar.]

Comment 15

[Michael La Guardia]

Beta 1 designation seems not to have made it into the keywords field.  Adding.

Comment 16

[Patrick C. Beard]

This is not a view manager bug, but a widget bug. If I change nsWindow::Scroll() 
to simply invalidate, rather than scroll the bits, I can't see any problem, 
therefore the problem is with the bit scrolling code itself. This is a nasty 
workaround, but may be the best we can do right now.

Comment 17

[Patrick C. Beard]

An alternative theory, is that when autoscrolling is happening, invalidates may 
be going to the wrong area, i.e. we may be underinvalidating, which is why my 
brute force solution works. Perhaps the problem is in the text selection 
mechanism itself.

Comment 18

[mjudge]

giving it to simon since it seems to be mac

Comment 19

[Kathleen :Brade]

reassign to beard for some kind of workaround or fix
Patrick--drag mjudge over to sit with you if you have any questions about 
selection.

Comment 20

[Patrick C. Beard]

This is a cosmetic problem. I propose deferral. The user can always windowshade 
and force a redraw.

Comment 21

[Eli Goldberg]

Err, is it really a cosmetic problem if the entire web browser content window is 
illegible? That sounds more functional. ;)

Nonetheless, erhaps drag-scrolling isn't as commonly used as I thought it was, 
given that there are no dupes of this bug after 4.5 months.

Comment 22

[leger]

Agreed - putting on PDT- radar for beta1.

Comment 23

[Patrick C. Beard]

I have a fix for this now. If you want to approve it, it's very low risk. Here's 
the patch:

Index: mozilla/layout/base/src/nsRangeList.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/base/src/nsRangeList.cpp,v
retrieving revision 1.180
diff -c -2 -r1.180 nsRangeList.cpp
*** nsRangeList.cpp	2000/02/10 09:17:02	1.180
--- nsRangeList.cpp	2000/02/24 01:41:41
***************
*** 2830,2833 ****
--- 2830,2835 ----
                if (dx != 0 || dy != 0)
                {
+                 // make sure latest bits are available before we scroll them.
+                 viewManager->Composite();
                  result = scrollableView->ScrollTo(scrollX + dx, scrollY + dy, 
NS_VMREFRESH_NO_SYNC);
  

Comment 24

[Patrick C. Beard]

The patch uses the view manager to handle any pending updates, before scrolling 
occurs, so that the correct image is scrolled.

Comment 25

[mjudge]

this seems quite reasonable. since we found the exact 1 line to fix this. I will 
now try to check in.

Comment 26

[mjudge]

got approval, got reviews. did checkin tests. waiting for green tree.

Comment 27

[mjudge]

fixed. 1 line. done

Comment 28

[Eli Goldberg]

Verified fixed on 2000022808 Mac OS & "1999122808" (this morning's) mislabeled
Linux build.

----

There's a small side-issue in which the content is slightly messed up at the top
of the page while drag-scrolling content on Mac OS.

(I also see page corruption messed up on one horizontal line when scrolling via
the vertical scroll bar on Mac OS.)

Will report these polish-issues when we're further along (unless mjudge would
like them now.)