Closed
Bug 262125
Opened 20 years ago
Closed 19 years ago
textarea scrolling bug in 1.7.x (and others?)
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: mathog, Unassigned)
Details
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&sessionid=username-session-0.603785894419165&folder=INBOX&sort=date&firstmessage=1"></a> </td></tr><tr><td colspan="2"> </td></tr> <form method="post" action="/cgi-bin/site_auth/neomail.pl?sessionid=username-session-0.603785894419165&firstmessage=1&sort=date&folder=INBOX&message_id=982b37d1a76eba4973114ecb2bfff3fc&action=composemessage&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.
|
||
Comment 1•20 years ago
|
||
What does "about:buildconfig" for that build say?
|
Reporter | |
Comment 2•20 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
|
|
||
Comment 3•20 years ago
|
||
Hmm... odd... I can't seem to reproduce with a current trunk build with pretty identical build settings...
|
|
Reporter | |
Comment 4•20 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
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
|
||
Comment 5•19 years ago
|
||
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/
|
|
||
Comment 6•19 years ago
|
||
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
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•