Bug 11767 - REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea
Summary: REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar, Regression
Depends on:
Blocks:
 
Reported: 2006-12-06 04:48 PST by David Kilzer (:ddkilzer)
Modified: 2017-07-18 08:30 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Kilzer (:ddkilzer) 2006-12-06 04:48:53 PST
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.
Comment 1 Mark Rowe (bdash) 2007-01-28 19:12:28 PST
<rdar://problem/4960271>
Comment 2 Sam Weinig 2007-02-11 16:12:32 PST
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().
Comment 3 Ojan Vafai 2009-03-04 14:48:42 PST
This no longer happens. Clicking on the resize handle doesn't focus it, but I'm not sure it should.
Comment 4 David Kilzer (:ddkilzer) 2009-03-04 18:44:58 PST
(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?
Comment 5 Ojan Vafai 2009-03-04 18:49:17 PST
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. 
Comment 6 Antonio Gomes 2010-04-23 04:32:24 PDT
still reproducible 3.5 years later on QtWebKit/Linux
Comment 7 Elliott Sprehn 2012-09-07 14:05:26 PDT
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.
Comment 8 Elliott Sprehn 2012-09-07 14:06:38 PDT
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
Comment 9 Elliott Sprehn 2012-09-07 14:12:45 PDT
(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.
Comment 10 Ryosuke Niwa 2012-09-18 09:41:32 PDT
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.