16631 - [DOGFOOD]If you select text and drag to the bottom of the browser window it crashes

Status: VERIFIED FIXED

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

Description

[Neil Marshall]

Launch the browser, click and drag the mouse to the bottom of the screen.  The
browser will crash.  Build 1999101608

Comment 1

[Sean Richardson]

Could not reproduce on Windows NT with 1999-10-17-09-M11.

Procedure followed:
1. Left-Click within browser window and keep left mouse button down.
2. Drag to bottom of window and beyond, to the bottom edge of the host OS
   desktop.
3. Try repeatedly, slowly and quickly, trying to click-drag off each of the
   four edges of the desktop.
4. Check console for messages.

Observed: No Crash, no unexpected console messages.

[e-mail], you marked the OS as "other" on the PC platform.
What was it?

Comment 2

[Neil Marshall]

Whoops.  Sorry I'm operating Win98

Comment 3

[Kathleen :Brade]

I don't see this problem on Macintosh.

Eli--can you confirm this is a win98 only problem?

Reassign to [e-mail] since he's been working in this area.

Comment 4

[kinmoz]

Accepting bug. marshall, do you have a stack trace for the crash that I can look
at?

Comment 5

[Neil Marshall]

No I don't... just using the binaries.  One thing I did figure out, is that it
only happens when I turn on the xul scrollbars.  When I use the default windows
scrollbars, it just scrolls the page.

Comment 6

[kinmoz]

This is a known bug, and one of the reasons why XUL scrollbars aren't on by
default. It's crashing in selection code because it uses anonymous content.

Comment 7

[Sean Richardson]

Confirmed with 1999-10-18-08-M11 on WinNT 4.0sp3:
If scrollbars are native, no crash.
If scrollbars are xul:

Actual Results:
1. Over three restarts of mozilla.exe, each time the contents of the window
   jumped to the top, much like what happens when dragging a scrollbar down

   if the pointer wanders left or right out of the scrollbar, except here
   the jump was not back to the origin, but to the top, when the origin of
   the drag was not the top.
2. Result 1 occurred once or twice; on the scecond or third try, CRASH

Comment 8

[rubydoo123]

Scrollbars are a must for dogfood and for beta -- proposing this be given
dogfood status.

Comment 9

[leger]

Putting on the PDT+ radar.

Comment 10

[kinmoz]

[e-mail] checked in some code to check for null in

    mozilla/layout/base/src/nsContentIterator.cpp     revision 1.33

that actually prevents us from crashing. But there are still some serious
selection problems like Selection AutoScrolling being broken when Gfx scrollbars
are turned on. I'll file these as a separate bugs.

Comment 11

[Eli Goldberg]

Can't reproduce using 1999110911 build on NT 4.0 SP5.

[e-mail] or [e-mail], would you like to also give this a quick
look and confirm that it's fixed? (I've never seen this bug firsthand.) Thanks!

Comment 12

[Sean Richardson]

Sorry, still seeing both the crash and the snap-back scrolling with the
1999-11-10-09-M12, 1999-11-09-11-M11, and 1999-11-08-09-M11 nightly binaries
on Win NT when GFX scrollbars are enabled - oddly, though, on different pages.

The crash happens reliably within 4 iterations of click-dragging beyond the
bottom of the canvas edge. Seen viewing http://www.infoworld.com/
Expected result: some sort of auto-scrolling, or nothing at all.
Actual result, no scrolling, immediate crash. (Same for all 3 builds)

The scrolling snap-back happens with 100% reliability when viewing
http://www.angustel.ca/update/up.html iff the window is scrolled down
below the headlines before trying to click-drag beyond the canvas' bottom edge.

Tested with:
Windows NT 4.0sp3, PCI Matrox Millenium video adapter (latest release driver),
Dr Watson disabled (usually there's not enough room on the boot drive for
a memory image file, and I prefer NT to stay up when an app crashes)
Tested with GFX-scrollbars as that's how I saw the crash before.

Query:
Will gfx-scrollbars be enabled by default by the time of the M12 release?

Will test with native scrollbars as well to see if that query matters.

Comment 13

[Sean Richardson]

Testing with native scrollbars, click-drag scrolling with 1999-11-09-11-M11 on
WinNT works properly for http://www.angustel.ca/update/up.html and many other
pages with no snap-back or crashing. On a page with a complex but clean table
layout (http://news.bbc.co.uk/) the click-drag selection and scrolling works
correctly horizontaly from column to column as well as vertically.
Same with the parts of Windows Update Mozilla can get into.

http://www.infoworld.com/ just plain crashes this build on use. Any click
will do it, click-drag makes no difference, scrollbar type makes no diff.
So this wasn't a good page to test with.

Summary:
1. With native scrollbars, click-drag selection and scrolling seems to be
   working properly. No crashes. Tested repeatedly and with many pages.
2. With GFX scrollbars, click-drag selection and scrolling is snapping back
   to the top of the page when the bottom of the canvas is reached. (This
   is a distinct bug, bug 17989). No crashes. Tested repeatedly and with many
   pages.

Observations:
1. This crash only ever seemed to happen when gfx scrollbars were turned on.
2. This crash was first seen shortly after gfx scrollbars first landed.
3. The crash seems to have been replaced by merely incorrect results,
   most of the time by 1999 10 19, and 100% of the time today.

This does look fixed.

Comment 14

[Eli Goldberg]

[e-mailed Kin to find out what he'd like to do with this bug. sidr@albedo, thanks
for your extremely thorough investigation!]

Comment 15

[Eli Goldberg]

Per sidr's detailed research & Kin's confirmation, rubber-stamping as Verified/
Fixed. Thanks!