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.
Version: unspecified → Trunk
maybe I described my problem too complex, sorry when someone has some questions I will give an answer
Product: Firefox → Core
QA Contact: general → layout.form-controls
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?
(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
> 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?
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?
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.
OK, I will try to save the website and look what happens, when I use IE and Opera.
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?
Opera shows the same behaviour like IE (Version 7)
> 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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> "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 ]
> 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.
> 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"
Yes, but it gets resized in different increments, which affects the scrolling behavior, since scrolling is handled independently on every resize.
> 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_ ]
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.
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_ ]
10 years ago
You need to log in before you can comment on or make changes to this bug.