Summary: When clicking on the scrollbar of an unfocused textarea, focus is not fully set on the textarea element since no caret is drawn and typing has no effect. (See Bug 11746 Comment #15 for behavior of other modern web browsers.) Steps to reproduce: 1. Load a page with a textarea (like this bug page). 2. Click in the web page (but outside of the textarea). 3. Click on the scrollbar part of the textarea (either the bar itself or its buttons--anywhere). Expected behavior: A caret should appear in the textarea, and typing should insert text into the textarea. Actual behavior: A focus ring is drawn around the textarea, but typing does nothing and no caret is drawn. Workaround: Once the textarea has "focus" with a mouse click in the scrollbar part, hit Tab, then Shift-Tab. Note that a caret is drawn and typing is possible within the textarea. Notes: Regression from shipping Safari 2.0.4 (419.3) on Mac OS X 10.4.8 (8L127). See also Bug 11746 Comment #15 for behavior of other modern web browsers.
<rdar://problem/4960271>
After a little investigating, it seems that this is happening because HTMLTextAreaElement::updateFocusAppearance() is not being called when the the <textarea> is focused by a mouse click to the scrollbar area. It works for tabbing into it because the tabbing mechanism (FocusController) calls HTMLTextAreaElement::focus() (which it probably shouldn't, but rather call Document::setFocusedNode() instead), which calls HTMLTextAreaElement:: updateFocusAppearance().
This no longer happens. Clicking on the resize handle doesn't focus it, but I'm not sure it should.
(In reply to comment #3) > This no longer happens. Clicking on the resize handle doesn't focus it, but I'm > not sure it should. I still see the same behavior described in Comment #0 with Safari 4 Developer Preview and WebKit nightly build r41431. What software were you using to test?
Oh crap. Sorry. I actually read the actual behavior backwards (as in, that it would get no focus rect). I even reread it to make sure.
still reproducible 3.5 years later on QtWebKit/Linux
The issue is a little more complicated than just "fully focusing". Gecko remembers the caret position so if you click in a middle of a textarea, unfocus it, then tab back into it or click the scrollbar your caret is still in the middle. WebKit doesn't store the caret position though, so we always put it back at the start when tabbing. It would be really weird if clicking the scrollbar on an unfocused textarea put the caret at the start since it's quite possible you can't see the start of the textarea when scrolling. The current behavior as described in this bug make sense in a world where we forget the caret position.
https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767xxxxxxxx https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767
(In reply to comment #8) > https://bugs.webkit.org/show_bug.cgi?id=11767https://bugs.webkit.org/show_bug.cgi?id=11767 > ... Woops. :( Messing with textareas in bugzilla and history items results in a bad time. Note that the behavior of browsers as described here is really weird. See: https://bugs.webkit.org/show_bug.cgi?id=11746#c15 We should probably decide if we want to match the IE6 behavior or the Gecko behavior.
I don't think we necessarily need to match other browsers here. The focus behavior is largely platform dependent; we should do whatever makes most sense on each platform. It sounds as if we're setting the focus but not moving the selection there.