408998 - text position doesn't get adjusted correctly in a resized input element

Status: NEW

(Core :: Layout: Form Controls, defect)

Description

[Rudolf Krist]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.9b2) Gecko/2007121120 Firefox/3.0b2

When I input text in an input element, which is resized dynamically to adapt to the text length, when the text is entered by "copy & paste".

Reproducible: Always

Steps to Reproduce:
1. go to http://del.icio.us/fukas78 (Javascript must be activated)
2. copy a string into the clipboard, which has a minimum length of 8 characters e.g. "abcdefghij"
3. select the tag input element (in the first line of the web site)
4. paste the string from clipboard into this input element
Actual Results:  
the text is pasted into the input element, the size of the input element was adapted to the string length, but the position of the displayed string is not updated to the new layout of the input element.
->
empty input element:
[     ]
actual resized input element with text "abcdefghij", entered by copy & paste:
[ ghij         ]

Expected Results:  
the text position has to be updated too
->
->
empty input element:
[     ]
actual resized input element with text "abcdefghij", entered by copy & paste:
[ abcdefghij   ]

If I select the text contained in the input element by clicking in the input element and moving the mouse (mouse button stays pressed) to the beginning of the text, the entire string is revealed:
[ ghij         ]
gets to
[ abcdefghij   ]

I have noticed the bug, when I used Firefox 3 Beta 2, but the same behaviour I can observe using Firefox 2.0.0.x
I have also checked Opera, Safari, IE, they didn't show this behaviour, they worked correctly.

the HTML-sourcecode of the input element:
<form class="crumbform" action="/" method="get">
<input value="/rudik/" name="root" type="hidden">
<input style="width: 182px;" name="crumb" class="crumb"> <!-- buggy elem. -->
</form>

the Javascript sourcecode responsible for the dynamical resizing:
// from http://del.icio.us/ui/static/delicious.js?v=61E-123
// ...
var Crumb = { // ...
   keyhandler: function(e) { // ...
      }}
      this.style.width = getTextSize(this.value, Crumb.sizer) + 40 + 'px'
}}

Comment 1

[Rudolf Krist]

The hidden text, that is not displayed correctly after it was pasted into the input element can also be revealed by clicking into the input element and pressing the HOME key of your keyboard.

Comment 2

[Rudolf Krist]

maybe I described my problem too complex, sorry when someone has some questions I will give an answer

Comment 3

[Boris Zbarsky [:bzbarsky]]

Sounds like resizing the scrollframe preserves the scroll position... I'd think this is usually a good thing.

Do Opera and IE lose the scroll position if you change the size from one too-small size to another too-small size?

Comment 4

[Rudolf Krist]

(In reply to comment #3)
> Sounds like resizing the scrollframe preserves the scroll position... I'd think
> this is usually a good thing.
> 
> Do Opera and IE lose the scroll position if you change the size from one
> too-small size to another too-small size?

There is no scroll bars in the input element, there is nothing to scroll at all. The text fits into the resized input element. did you try out the reproducing steps with del.icio.us?
Regards
Rudi

Comment 5

[Boris Zbarsky [:bzbarsky]]

> There is no scroll bars in the input element

Yes, but there is nevertheless a scrollframe inside it; the innards are just overflow:hidden.

> there is nothing to scroll at all

When there's enough text that it's longer than the input there is something to scroll, right?  The scrolling mechanism is present whatever length the text is.

> did you try out the reproducing steps with del.icio.us?

Yes, of course.  Did you try answering my question from comment 3?

Comment 6

[Rudolf Krist]

I don't know any site, using this mechanism to resize from one too-small size to another too-small size. So I couldn't check it.

Was it your intention to formulate your question from comment 3, to be looking like IE and Opera are buggy and Firefox works correctly?

Comment 7

[Boris Zbarsky [:bzbarsky]]

You could make a copy of this site and change the code to resize to a too-small size...

And I didn't have any "intention" past gathering information on how IE and Opera behave under various conditions here; I do have a hypothesis that there are situations where the IE/Opera behavior might give worse results than the Gecko behavior.  I'll be able to test Opera in a week or so when I get back, but I can't test IE.

Comment 8

[Rudolf Krist]

OK, I will try to save the website and look what happens, when I use IE and Opera.

Comment 9

[Rudolf Krist]

When the input element is resized to a too-small size using IE, then the tail of the text is shown in this element when I follow the reproduction steps.

Another question Boris:
Why do you thing it is a good Idea to handle input when it is typed in character-by-character differently to handling input when it is entered by copy-and-paste?

Comment 10

[Rudolf Krist]

Opera shows the same behaviour like IE (Version 7)

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Why do you thing it is a good Idea to handle input when it is typed in
> character-by-character differently

Do we handle it differently?  That is, if the resize happens off a timeout such that you can type all the characters and then the resize happens, is the behavior different?  I would be quite surprised if it is.

I guess my real question about the IE behavior was whether resizing keeps the current caret position in view, whether that position is at the end of the text or not.

I guess the key here is that making flailing changes here is not a good idea.  What's needed is a full behavior spec for scrolling behavior on resizes that can then be implemented.  If someone can come up with such a spec, that would be very helpful in getting the bug fixed quicker.

Comment 12

[Rudolf Krist]

> "Do we handle it differently?"
Yes we do.

If I type the input "abcdefghij" character-by-character I get:
[ abcdefghij   ]

If the string "abcdefghij" is entered by copy&paste using Firefox, I get:
[ ghij         ]
(only the tail of the string is visible!)

copy&paste, using IE, Opera etc.:
[ abcdefghij   ]

Comment 13

[Boris Zbarsky [:bzbarsky]]

> If I type the input "abcdefghij" character-by-character

On the site?  But in that case, the site runs different JS from when you paste the whole string in.  You have to change what the site does to actually compare how pasting and typing compare.  See the rest of that paragraph you started quoting in comment 11.

Comment 14

[Rudolf Krist]

> But in that case, the site runs different JS from when you paste the
> whole string in.

No I dont think so, because the input element gets resized identically, regardless of which kind of input is used, "copy&paste" or "character-by-character"

Comment 15

[Boris Zbarsky [:bzbarsky]]

Yes, but it gets resized in different increments, which affects the scrolling behavior, since scrolling is handled independently on every resize.

Comment 16

[Rudolf Krist]

> I guess my real question about the IE behavior was whether resizing keeps 
> the current caret position in view, whether that position is at the end of 
> the text or not.

I will highlight the caret with the "_" character after "abcdefghij" was entered:
character-by-character, all browsers
[ abcdefghij_  ]
copy&paste, firefox
[ ghij_        ]
copy&paste, IE+Opera
[ abcdefghij_  ]

Comment 17

[Boris Zbarsky [:bzbarsky]]

That still doesn't answer my question.

Oh, well.  I'll try to look into this, but that's not likely to happen until May at best.

Comment 18

[Rudolf Krist]

Now I think I have got the point, using other browsers the adjusting of the scroll position occurs after the input element was resized.
Firefox adjusts the scroll position of the text first and then it resizes the box.

this behavour can be tested with following input strings (I think the length of the strings can depend on fontsize, default OS settings etc., I use WinXP)

Firefox (copy&paste input):
empty box:    [ _   ]
input "123":  [ 123_   ]
input "1234": [ 234_    ]