11767 – REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea

REOPENED Bug 11767

REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea

https://bugs.webkit.org/show_bug.cgi?id=11767

Summary REGRESSION: Clicking on scrollbar of textarea does not fully focus the textarea

David Kilzer (:ddkilzer)

Reported 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.

Attachments
Add attachment proposed patch, testcase, etc.

Mark Rowe (bdash)

Comment 1 2007-01-28 19:12:28 PST

<rdar://problem/4960271>

Sam Weinig

Comment 2 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().

Ojan Vafai

Comment 3 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.

David Kilzer (:ddkilzer)

Comment 4 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?

Ojan Vafai

Comment 5 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.

Antonio Gomes

Comment 6 2010-04-23 04:32:24 PDT

still reproducible 3.5 years later on QtWebKit/Linux

Elliott Sprehn

Comment 7 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.

Elliott Sprehn

Comment 8 2012-09-07 14:06:38 PDT

Elliott Sprehn

Comment 9 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.

Ryosuke Niwa

Comment 10 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.

Note You need to log in before you can comment on or make changes to this bug.

Status REOPENED

Resolution

Priority P2

Severity Normal

Classification Unclassified

Version 420+

Hardware Mac

OS OS X 10.4

Product WebKit

Component Forms

Assignee

Nobody

Reported

2006-12-06 04:48 PST

Modified

2017-07-18 08:30 PDT History

CC List

6 users Show

URL

Keywords InRadar, Regression

Depends on

Blocks