11767 2006-12-06 04:48:53 -0800 REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea 2017-07-18 08:30:08 -0700 1 1 1 Unclassified WebKit Forms 420+ Mac OS X 10.4 REOPENED InRadar, Regression P2 Normal --- 1 ddkilzer webkit-unassigned esprehn jchaffraix jonlee rniwa tonikitoo webkit-bug-importer oldest_to_newest 43113 0 ddkilzer 2006-12-06 04:48:53 -0800 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. 31247 1 mrowe 2007-01-28 19:12:28 -0800 <rdar://problem/4960271> 24139 2 sam 2007-02-11 16:12:32 -0800 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(). 112295 3 ojan 2009-03-04 14:48:42 -0800 This no longer happens. Clicking on the resize handle doesn't focus it, but I'm not sure it should. 112337 4 ddkilzer 2009-03-04 18:44:58 -0800 (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? 112339 5 ojan 2009-03-04 18:49:17 -0800 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. 216371 6 tonikitoo 2010-04-23 04:32:24 -0700 still reproducible 3.5 years later on QtWebKit/Linux 714951 7 esprehn 2012-09-07 14:05:26 -0700 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. 714955 8 esprehn 2012-09-07 14:06:38 -0700 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 714960 9 esprehn 2012-09-07 14:12:45 -0700 (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. 722869 10 rniwa 2012-09-18 09:41:32 -0700 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.