246767 - programmatically adding text to a multiline textbox with vertical scrollbar makes scrollbar scroll to top

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Duma Lucian]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

The whole thing started when I try to intercept the press of the TAB key on the
keyboard. When I press TAB I want to have a normal efect like in all the text
editors: to introduce a TAB space. Here is some code:
Code:
<tabbox>
  <tabs>
    <tab id="file_name" label="Undefined"/>
  </tabs>
  <tabpanels flex="1">
    <tabpanel>
   <textbox id="code" multiline="true" flex="1"  onkeypress="tabpress(event)"/>     
    </tabpanel>
  </tabpanels>
</tabbox>


The tabpress function inserts 2 blank spaces at the curent position of the
cursor, like this:
Code:
function tabpress(event)
{
   if(event.keyCode==9) //if I pressed the TAB key
   {
      var tab="";//init the tab
      var i;
      var code = document.getElementById('code');
      var pos = code.selectionStart; //get the position of the cursor
      
      //we set the tab size according to the settings
      var tabsize = document.getElementById('tabsize');
      for(i=0; i<tabsize.value; i++)
         tab=tab + " ";//put spaces in tab acordinfg to the preferences saved in
a hidden label with id=tabsize
      
      temp1=code.value.substring(0, pos); //get the text until the position of
the cursor
      temp2=code.value.substring(pos, code.value.length); //get the text after
the position of the cursor
      code.value=temp1+tab+temp2;//put the tab in the text
      code.focus();//refocus the test
      code.selectionStart=pos+tab.length;
      code.selectionEnd=pos+tab.length; //set the cursor to its corect position
   }else return false;   
}

After this I get the TAB in in the text but the scrolling position of the
textboxis at the start, not at the place where the TAB was inserted. 

The exact behavior I see now, even in the www.xulplanet.com/forum!
Here, try it yoursef:
Start with Mozilla on the forum.
Than try to write more text in the textbox of a Post Reply until you get a
scroll bar in the right. Now press Code button or Quote or any buttton from
above the text. This introduces a coresponding text in the textbox and the
scrolling position is at the start of the text you just wrote. 

Reproducible: Always
Steps to Reproduce:
1. make a textbox with multiline="true"
2. insert some text (whatever, doesn't matter what) or some \n until you get a
scrollbar to the right of the textbox. Position the cursor at the end of this text
3. make a function that gets the textbox by id (getElementById) and appends some
 new text on the old one
4. with the focus on the textbox and with the cursor on the last character of
the text, call that function, let's say from a button


Actual Results:  
Result: the new text is appended, ok, but the scrolling position of the textbox
is at the begining not at the position where the text was appended. However, the
cursor position is where the text was appended

Expected Results:  
The position of the scrolling should be set according to the position where the
new text was inserted. (or at least to the cursor position)

Thank you, hope you can set this right.
I myself am a little fan of Mozilla. The bug doesn't exist in IE
The best  way to see this is on the xulplanet.com/forum, like I explained earlier
Thanks again. Succes!

Comment 1

[Xanthor Sccas]

Yes, this occures also with simple (X)HTML textareas :¬/

By the way, I see it under linux, so maybe you should set OS to ALL...

Comment 2

[Gervase Markham [:gerv]]

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 3

[Xanthor Sccas]

I can reproduce the bug with this testcase : http://taupe.batcave.net/textarea.xhtml

Comment 4

[Benoît]

Confirmed. I have been seeing this for AGES!
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.8) Gecko/20051030 SeaMonkey/1.0b

This is a Core bug.

Product -> Core
Component -> Layout: Form Controls

Comment 5

[Benoît]

Reworded summary.

Comment 6

[Benoît]

I've tried to get a regression window on this. However, it goes at least two years back. This might not be a regression, but a real bug.

Comment 7

[Benoît]

Attachment: testcase

It's not as minimal as it could be, but I did my best.

Type in random text that spreads over multiple lines, causing the textbox to have a vertical scrollbar. Then click the link on the bottom to add text to it via JavaScript. Watch the textbox' scrollbar jump up.

Comment 8

[Benoît]

Forgot to add the testcase keyword.

I've done some more regression window testing, and the bug is present in 1.5a and 1.4a.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Notes based on IRC discussion:

1)  foo.value += "x" is identical to foo.value = foo.value + "x" per ECMA-262
    spec.
2)  Therefore this bug is about general setting of .value and how it should be
    treated.
3)  We may (or may not) want to treat XUL textbox and HTML textarea differently
    or provide different APIs to access the desired behavior (eg in XUL we could
    have append() and insertAtCaret() methods on textbox).
4)  It might make sense to either unmutate this bug and file a new one on HTML
    or to file a new bug for XUL; in either case the HTML bug should block the
    XUL bug.

Comment 10

[George Miroshnykov ( :gmiroshnykov )]

Also affects horizontal scrolling.

With this bug in effect, there are no means to scroll XUL multiline textboxes / HTML textareas from Javascript under such conditions.
IMHO this is a basic UI functionality.
Any plans to fix this bug or implement XUL textboxes scrolling methods?
Or are there any workarounds?

Comment 11

[Aaron]

I am experiencing major difficulties as a result of this bug. Will there ever be a fix?

Comment 12

[Boris Zbarsky [:bzbarsky]]

See comment 9.  It's not clear what the behavior should be, in general.  Should scroll position always be preserved on value set?  Does that make sense?  If not, what should happen?

Once there's some decision on what the behavior should be, one can start thinking about how to make it so.

Comment 13

[Benoît]

However, seeing as this bug has been open for three years now, when will a decision be made?