Last Comment Bug 231389 - Textarea scrolls to top after changing its .value, regardless of cursor position
: Textarea scrolls to top after changing its .value, regardless of cursor position
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Editor (show other bugs)
: Trunk
: x86 All
: -- normal with 9 votes (vote)
: mozilla1.9.3a4
Assigned To: :Ehsan Akhgari (away Aug 1-5)
:
Mentors:
http://test.wikipedia.org/w/wiki.phtm...
Depends on:
Blocks: 232405
  Show dependency treegraph
 
Reported: 2004-01-18 13:55 PST by Erik Moeller
Modified: 2012-08-02 12:38 PDT (History)
20 users (show)
darin.moz: blocking1.8.1-
ehsan: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
A HTML/JavaScript test case for this bug (1.35 KB, text/html)
2004-01-18 18:52 PST, Erik Moeller
no flags Details
Problem solved (1.42 KB, text/html)
2004-04-02 23:19 PST, Erik Moeller
no flags Details
Patch to fix the problem w/o a workaround (1.11 KB, patch)
2004-06-24 09:12 PDT, Tom Hennen
mikepinkerton: review+
Details | Diff | Splinter Review
Patch v2 (1.15 KB, patch)
2004-06-28 04:25 PDT, Tom Hennen
mikepinkerton: review+
Details | Diff | Splinter Review
mozilla-input-selection-scroll-on-focus.patch (838 bytes, patch)
2007-11-19 07:04 PST, Priit Laes
no flags Details | Diff | Splinter Review
Patch (v1) (3.22 KB, patch)
2010-03-16 10:56 PDT, :Ehsan Akhgari (away Aug 1-5)
roc: review+
Details | Diff | Splinter Review

Description Erik Moeller 2004-01-18 13:55:53 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624, also tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040111 Firebird/0.8.0+

After changing the value of a textarea via JavaScript, it scrolls to the top. If
the cursor is subsequently set via selectionStart/selectionEnd or
setSelectionRange(a,b), the cursor itself is correctly set, but the textarea
view is still at the top. Calls to focus() make no difference either. 

This affects comment formatting toolbars, where we want to change the selection
to apply tags like "bold" and "italic" around it. This works as long as the
selection is not beyond the textarea visible range, i.e. as long as no scrolling
is required to make it. Any selection that goes beyond that triggers the bug:
the textarea scrolls to the top after its contents are overwritten.

Reproducible: Always

Steps to Reproduce:
1. Go to http://test.wikipedia.org/w/wiki.phtml?title=Main_Page&action=edit
2. Scroll to the bottom
3. Select some text
4. Click the "bold" button
Actual Results:  
Textarea view scrolls to top. When you press a non-dead key, you're in the right
position again (the cursor is correctly set in this script).

Expected Results:  
Textarea view should not have scrolled, or there should be a JavaScript method
to change the selection text without scrolling.

The script used is at
http://test.wikipedia.org/style/wikibits.js
Comment 1 Erik Moeller 2004-01-18 14:03:11 PST
Another example:
http://www.massless.org/mozedit/
Comment 2 Boris Zbarsky [:bz] 2004-01-18 18:22:00 PST
> After changing the value of a textarea via JavaScript, it scrolls to the top.

This part is correct -- you have wiped out the old text completely, so the old
insertion point is lost.

> cursor itself is correctly set, but the textarea view is still at the top

That sounds like a bug.  Over to editor core.  If you could attach a testcase to
this bug, that would be great.
Comment 3 Erik Moeller 2004-01-18 18:52:01 PST
Created attachment 139397 [details]
A HTML/JavaScript test case for this bug
Comment 4 Erik Moeller 2004-01-18 18:52:48 PST
Does this help, Boris?
Comment 5 Jesiah S 2004-02-03 09:29:00 PST
I see this using testcase on LInux 2004020207
Comment 6 Erik Moeller 2004-04-02 23:19:04 PST
Created attachment 145368 [details]
Problem solved

JavaScript that solves this problem
Comment 7 Tom Hennen 2004-06-24 09:12:09 PDT
Created attachment 151619 [details] [diff] [review]
Patch to fix the problem w/o a workaround

This patch has the textarea scroll the cursor into view whenever the selection
changes.  This seems to be the appropriate behavior.  With it the above
workaround is no longer required.
Comment 8 Tom Hennen 2004-06-24 09:21:02 PDT
Comment on attachment 151619 [details] [diff] [review]
Patch to fix the problem w/o a workaround

The workaround worked, but this is nicer.
Comment 9 Mike Pinkerton (not reading bugmail) 2004-06-24 10:20:25 PDT
Comment on attachment 151619 [details] [diff] [review]
Patch to fix the problem w/o a workaround

r=pink, though i know nothing about this code ;)
Comment 10 Daniel Glazman (:glazou) 2004-06-24 11:34:12 PDT
Comment on attachment 151619 [details] [diff] [review]
Patch to fix the problem w/o a workaround

>+  rv = selection->AddRange(range);
>+  // scroll the new selection into view
>+  // ignore any scrolling errors.
>+  mTextSelImpl->ScrollSelectionIntoView(nsISelectionController::SELECTION_NORMAL, 
>+    nsISelectionController::SELECTION_FOCUS_REGION, PR_TRUE);
>+  return rv;

You should probably test rv before the call to ScrollSelectionIntoView,
return it if NS_FAILED(rv) and return NS_OK after the call.
Comment 11 Richard Silverstein 2004-06-25 14:58:09 PDT
Sorry for being untutored about these things, but how does one install the
attachment so that it will fix the bug?  This bug has been driving me crazy for
months & I'd dearly love to fix it.

Are you perhaps in a testing stage & will reveal this fix & installation
protocols later?
Comment 12 Jesiah S 2004-06-27 08:28:19 PDT
d/l & extract
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-source.tar.bz2
apply patch using http://www.mozilla.org/build/unix-cheatsheet.html#applyPatch
make .mozconfig using http://webtools.mozilla.org/build/config.cgi
`make -f client.mk build`
if you need any other help contact irc://moznet/#mozillazine
Comment 13 Richard Silverstein 2004-06-27 17:05:53 PDT
(In reply to comment #12)
> d/l & extract
>
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/mozilla-source.tar.bz2
> apply patch using http://www.mozilla.org/build/unix-cheatsheet.html#applyPatch
> make .mozconfig using http://webtools.mozilla.org/build/config.cgi
> `make -f client.mk build`
> if you need any other help contact irc://moznet/#mozillazine

when I try to save the .tar file to my desktop & open it w. winzip I get an
error saying it cannot open the file since it doesn't appear to be a legitimate
archive file.  I don't understand how one's supposed to use the Unix
Configurator.  Also, don't understand how to follow the patch cheatsheet
instructions.  I'm still totally confused about what one needs to do to fix the
problem or whether it's even possible to do so.
Comment 14 Tom Hennen 2004-06-28 04:25:29 PDT
Created attachment 151854 [details] [diff] [review]
Patch v2

Now checking the return value per comments.  Not using NS_ENSURE_SUCCESS as
this really isn't the sort of place we'd want to assert.
Comment 15 Jesiah S 2004-06-28 06:21:27 PDT
Sorry Richard, I thought you where the reporter who is using Linux. 
You can patch/compile Mozilla using the instructions located at
http://www.mozilla.org/build/win32.html.  This option is the most difficult of
the two and it will take hours to finish.

Your second option is to wait untill this patch is checked in to the tree.  When
this happens, the next nightly will have this patch.  The nightlys are located
at http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest/.
Comment 16 Mike Pinkerton (not reading bugmail) 2004-09-02 07:16:13 PDT
Comment on attachment 151854 [details] [diff] [review]
Patch v2

again, r=pink but i'm not the best person to review this.
Comment 17 Adam Hauner 2004-10-10 04:22:28 PDT
Tom Hennen: Do you plan land it in 1.8 timeframe? What's next step on this way,
if Mike Pinkerton review your last patch?
Comment 18 Yuh-Ruey Chen 2005-05-17 07:14:51 PDT
Not sure if this is relevant to the code, but since only selectionStart is
considered when scrolling the selection into view, perhaps only the code for
scrolling selection into view should be called only if selectionStart has
changed.  That would happen when setting selectionStart to a different value or
setting selectionEnd to a value less than selectionStart.  A little optimization.
Comment 19 Yuh-Ruey Chen 2005-05-24 02:04:03 PDT
A case where the JS workaround is still needed even if patch is checked in:

1) Enter enough text to make the scroll bar appear.
2) Select some text or a position in the text, so that the selection's
y-position is greater than clientHeight.
3) Scroll down a bit, so that the selected text is still in view.  Denote
current scrollTop as A.
4) Set value.  scrollTop=selectionStart=selectionEnd=0.
5) Set selectionStart/selectionEnd.

The textarea scrolls until the selected text is in view.  The selection should
be displayed at the bottom of the textarea.  However the new scroll position is
not A - at position A, the selection should not appear at the bottom of the
textarea.

Is this intended?
Comment 20 Steve England [:stevee] 2006-03-27 08:36:58 PST
Requesting attention / blocking for 2.0 via IRC request.
Comment 21 Darin Fisher 2006-06-14 10:29:11 PDT
Not going to block 1.8.1 for this, but we'd happily consider a patch once it has baked on the trunk.
Comment 22 Priit Laes 2007-11-19 07:04:45 PST
Created attachment 289312 [details] [diff] [review]
mozilla-input-selection-scroll-on-focus.patch

Updated patch, works for me ;)
Comment 23 :Ehsan Akhgari (away Aug 1-5) 2010-03-16 10:56:42 PDT
Created attachment 432855 [details] [diff] [review]
Patch (v1)

Patch + test.
Comment 24 :Ehsan Akhgari (away Aug 1-5) 2010-03-17 14:38:03 PDT
Comment on attachment 432855 [details] [diff] [review]
Patch (v1)

bz's out, switching the review request to roc.
Comment 25 :Ehsan Akhgari (away Aug 1-5) 2010-03-18 11:09:51 PDT
http://hg.mozilla.org/mozilla-central/rev/ba70a0cb9240
Comment 26 Alice0775 White 2012-08-02 12:38:58 PDT
*** Bug 779913 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.