Steps to reproduce: 1. Load the testcase. 2. Click the button labeled "Focus the textarea". 3. Wonder whether anything happened. 4. Press an arrow key. 5. Realize there was a blinking insertion point at the end of the textarea, where it was invisible because it was scrolled off.

See also bug 232405, "textbox/textarea doesn't scroll if I change cursor position with setSelectionRange, selectionStart, etc."

See also bug 64170, same bug for textboxes.

Patch taken from bug 231389. Seems to fix bug 353539, bug 232405 and bug 231389.

It should be noted that also happens on Win/Linux amd64/x86

I think you want to do async scroll here, unless there's a very strong reason to do sync. The sync scroll won't flush out layout before scrolling, so if the content gets updated but layout hasn't changed yet (e.g. if we make setting .value not flush layout) the scroll attempt could fail (because there's nothing to scroll to yet). I wonder whether it's possible to write a test for this, actually... I can't think of anything offhand that would break with an async scroll.

Here comes the asynchronous version. It doesn't seem that it fully fixes the current issue... (check the testcase attached to this bug), but it at least makes testcases from bug 232405 and bug 231389 working...

Hmm. That's very odd. I would expect it to work just fine on the testcase in this bug...

Any chance it gets approval? It at least fixes some of the major issues..

Well. If it doesn't fix this bug, then it's kind of wrong, no? Can you tell what's going on?

Well, it fixes the other two bugs ;)

It's attached to this bug, though. And the point is, if it doesn't fix this bug something is wrong. Which means it's likely to break other things. And at this point in the cycle we'd rather let old bugs be than create new ones. If you don't plan to debug what's going wrong with the latest patch, please let me know and I'll try to find time to, I guess...

OK, over here neither of the two patches fixes this bug. This is no surprising: the focus() call doesn't even end up in SetSelectionInternal(). Sounds like the second patch should be placed on a bug it does in fact fix (at which point we should indeed review it and check it in), and we still need a fix for this bug.

Comment on attachment 288837 [details] [diff] [review] mozilla-input-selection-scroll-on-focus.patch Nice catch, so marking this one obsolete ;)

Patch + test

Comment on attachment 432861 [details] [diff] [review] Patch (v1) bz's out, switching the review request to roc.