textarea scrolling bug in 1.7.x (and others?)

RESOLVED EXPIRED

Status

SeaMonkey
General
RESOLVED EXPIRED
14 years ago
12 years ago

People

(Reporter: David Mathog, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

There's an odd scrolling bug I've seen occasionally using neomail on
various versions of Mozilla up through 1.7.3.  In a large textarea
full of text if the text is centered (using the scroll bar) and then
a left click (to select) and drag upward (or downward) past the
top(/bottom) of the box, Mozilla slows to a crawl and the textarea
scrolls, but _very_ slowly, in the desired directiion, and it may take
a _very_ long time before control of the window is regained.  While
this is happening X or Mozilla (varies) goes to 99% CPU.
This seems to be some sort of redraw issue, since it can be
cleared by dragging another window over the (slowly scrolling)
textarea.  Sometimes this will work ok the first time, and then go
to the slow glitch on the 2nd or 3rd attempts.  Normal scrollbar control
of the textarea is not a problem.

An example page, edited down from a neomail page, is pasted below my
signature.

This has been seen most recently on:

Kernel 2.6.8.1 (SMP)
XFree86 4.3, patch level 32.1.100mdk
Mandrake 10.0
Mozilla 1.7.3
Tyan S2468UGN mobo
Dual Athlon MP 2000+
ATI Rage XL (built into motherboard)

It has also been observed with different graphics cards and single
processor systems, so far, only on linux though.

No other scrolling problems in other applications have been noted.  It does
not appear to be a generic X11 related scrolling problem.  Example:  nedit
scrolls without problems up and down on a similar mouse drag/select operation.


Thanks,

David Mathog 


Example html to demonstrate bug:
<html><head><title>NeoMail - UserName</title>

<style type="text/css">

</style></head>
<body  bgcolor="#ffffff">

<table align="center" border="0" cellpadding="1" cellspacing="1" width="90%">
<tbody><tr><td colspan="2" align="left" bgcolor="#002266">
<font color="#ffffff" face="Arial, Helvetica" size="3">
<b>COMPOSE MESSAGE</b></font>
</td></tr><tr><td colspan="2" align="left" bgcolor="#dcdcdc">
<a
href="https://site.com/cgi-bin/site_auth/neomail.pl?action=displayheaders&amp;sessionid=username-session-0.603785894419165&amp;folder=INBOX&amp;sort=date&amp;firstmessage=1"></a>
</td></tr><tr><td colspan="2">&nbsp;</td></tr>
<form method="post"
action="/cgi-bin/site_auth/neomail.pl?sessionid=username-session-0.603785894419165&amp;firstmessage=1&amp;sort=date&amp;folder=INBOX&amp;message_id=982b37d1a76eba4973114ecb2bfff3fc&amp;action=composemessage&amp;composetype=reply"
enctype="multipart/form-data" name="composeform"></form>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<b>From:</b>
</td><td align="left" bgcolor="#dddddd" valign="middle">
blah;
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<a href="javascript:GoAddressWindow('to')" tabindex="0"><b>To:</b></a>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="to" value="somebody@somewhere.com" size="70" type="text">
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<a href="javascript:GoAddressWindow('cc')" tabindex="0"><b>CC:</b></a>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="cc" size="70" type="text">
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<a href="javascript:GoAddressWindow('bcc')" tabindex="0"><b>BCC:</b></a>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="bcc" size="70" type="text">
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<b>Reply-To:</b>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="replyto" size="70" type="text">
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<b>Attachment:</b>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="attachment" size="60" tabindex="0" type="file"><input name="Add"
value="Add" tabindex="0" type="submit">
</td></tr>
<tr><td align="right" bgcolor="#dddddd" valign="middle" width="75">
<b>Subject:</b>
</td><td align="left" bgcolor="#dddddd" valign="middle">
<input name="subject" value="Re: funny select scrolling" size="70" type="text">
</td></tr>
<tr><td colspan="2" bgcolor="#eeeeee">
<textarea name="body" rows="15" cols="72" wrap="hard">
Use the scroll bar to move to the middle of the
text box.  Left click and drag up until it scrolls.
Repeat a few times.  Eventually the "select scrolling"
will become very slow.  Dropping another window
over this window, to cover it, will let the operation
complete, which suggests that it is a redraw problem.

 0 This is a lot of text
 1 This is a lot of text
 2 This is a lot of text
 3 This is a lot of text
 4 This is a lot of text
 5 This is a lot of text
 6 This is a lot of text
 7 This is a lot of text
 8 This is a lot of text
 9 This is a lot of text
10 This is a lot of text
11 This is a lot of text
12 This is a lot of text
13 This is a lot of text
14 This is a lot of text
15 This is a lot of text
16 This is a lot of text
17 This is a lot of text
18 This is a lot of text
19 This is a lot of text
20 This is a lot of text
21 This is a lot of text
22 This is a lot of text
23 This is a lot of text
24 This is a lot of text
25 This is a lot of text
26 This is a lot of text
27 This is a lot of text
28 This is a lot of text
29 This is a lot of text
30 This is a lot of text
31 This is a lot of text
32 This is a lot of text
33 This is a lot of text
34 This is a lot of text
35 This is a lot of text
36 This is a lot of text
37 This is a lot of text
38 This is a lot of text
39 This is a lot of text
40 This is a lot of text
41 This is a lot of text
42 This is a lot of text
43 This is a lot of text
44 This is a lot of text
45 This is a lot of text
46 This is a lot of text
47 This is a lot of text
48 This is a lot of text
49 This is a lot of text
40 This is a lot of text
51 This is a lot of text
52 This is a lot of text
53 This is a lot of text
54 This is a lot of text
55 This is a lot of text
56 This is a lot of text
57 This is a lot of text
58 This is a lot of text
59 This is a lot of text
60 This is a lot of text
61 This is a lot of text
62 This is a lot of text
63 This is a lot of text
64 This is a lot of text
65 This is a lot of text
66 This is a lot of text
67 This is a lot of text
68 This is a lot of text
69 This is a lot of text
</textarea>
</td></tr>
<tr><td align="left" valign="top">
<input name="Send" value="Send" type="submit">
</td>

 <!-- End of message composition form -->
<form method="post" action="/cgi-bin/site_auth/neomail.pl"
enctype="application/x-www-form-urlencoded"></form>
<td align="left" valign="top">
<input name="Cancel" value="Cancel" type="submit">
</td></tr></tbody></table>



</font><p align="center"><font face="Arial, Helvetica"><font size="1"><br>
<a href="http://neomail.sourceforge.net/">
NeoMail</a> version 1.24<br>
</font></font></p></body></html>



Reproducible: Always
Steps to Reproduce:
1.Described in main message
2.
3.

Actual Results:  
Apparently some redraw problem, slows X11 and/or Mozilla to a crawl.

If I had to guess it would be that when this happens the program tries to scroll
1 pixel at a time and gets way behind the cursor movement, which then stores
up a huge number of scroll events, all of which have to execute.

Expected Results:  
drag select should scroll normally, as if the scroll control had been used.

The theme is "classic modern".  I have not tested to see if theme matters.
What does "about:buildconfig" for that build say?
(Reporter)

Comment 2

14 years ago
about:buildconfig

Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe
-I/usr/X11R6/include

Configure arguments
--enable-extensions=default,irc,tasks,negotiateauth --disable-tests
--disable-debug '--enable-optimize=-O2 -gstabs+' --without-system-nspr
--without-system-zlib --without-system-jpeg --without-system-png
--without-system-mng --without-system-mng --enable-crypto
Hmm... odd... I can't seem to reproduce with a current trunk build with pretty
identical build settings...
(Reporter)

Comment 4

14 years ago
I've seen this scrolling problem on two different AMD motherboards
(Tyan S2468UGN and Asus A7V266E) with AMD MP (dual) and XP (single)
processors, respectively, both with Mandrake 10.0.  No shortage
of memory anywhere.

Window manager problem???  I've seen this scrolling problem with
other window managers but I generally use blackbox. Mandrake 10.0 has
blackbox 0.65.  Deinstalled that RPM and went to 0.70.beta2 from
sourceforge (built from source).  Same behavior. Wait,
belay that observation.  Scrolling in the textarea now works
correctly on the Asus machine, which uses the XIG X11 server, but
is still messed up on the Tyan machine, which uses  XFree86
version: 4.3.0.1.

On Mandrake 9.2 (some of those here too, with the Asus board and XIG X11
server) there is no scrolling problem using blackbox 0.65.

In any case, maybe running Blackbox 0.65 as the window
manager will increase the odds that you'll see this behavior?

The problem is easier to trigger on really large textareas.  Here's an
example (from my mail) which really does a number when it triggers the bug.
X11 usage goes to 99.8% (ouch!) on the Mandrake 10.0 Xfree86 Tyan S2468UGN
machine (dual processors), blackbox 0.70beta2.  

 ftp://saf.bio.caltech.edu/pub/pickup/neomail.html

Other variables, umm, screen size?  xdpyinfo shows screen #0 on the
machine still having problems as:

screen #0:
  dimensions:    1024x768 pixels (347x260 millimeters)
  resolution:    75x75 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32

Both mandrake 10.0 machines use 2.6.8.1 kernels, although the Tyan's
has SMP compiled in and the Asus's does not.

Just because it bears repeating, a similar drag operation off the top in
NEDIT (for instance) isn't a problem on any of these platforms.  So this
isn't a generic scrolling problem.

Thanks
Product: Browser → Seamonkey
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.