Bug 8324 - REGRESSION: textarea :focus not applied immediately
: REGRESSION: textarea :focus not applied immediately
Status: RESOLVED FIXED
: WebKit
New Bugs
: 420+
: Macintosh Mac OS X 10.4
: P1 Normal
Assigned To:
: http://amonre.org/pub/css/textarea-fo...
: Regression
:
:
  Show dependency treegraph
 
Reported: 2006-04-11 02:33 PST by
Modified: 2006-04-16 22:48 PST (History)


Attachments
Implement formControlIsBecomingFirstResponder (11.75 KB, patch)
2006-04-12 11:14 PST, mitz@webkit.org
no flags Review Patch | Details | Formatted Diff | Diff
Implement formControlIsBecomingFirstResponder (12.90 KB, patch)
2006-04-12 11:52 PST, mitz@webkit.org
darin: review+
Review Patch | Details | Formatted Diff | Diff


Note

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


Description From 2006-04-11 02:33:01 PST
OVERVIEW:

When selecting a textarea, its :focus selector is not always applied directly.

STEPS TO REPRODUCE:

1. Open the example at <http://amonre.org/pub/css/textarea-focus/>.
2. Click in the textarea to focus it.
The textarea's background color stays red, but it should be green.
3. Switch to another window or tab, and select the window or tab containing the textarea.
The textarea's background color turns green.

EXPECTED RESULTS:

In the example: the textarea's background color should be green whenever it is selected.

ACTUAL RESULTS:

In the example: the textarea's background color stays red when selecting the textarea. The textarea's background color turns green when re-focusing the window containing the textarea.
------- Comment #1 From 2006-04-12 07:48:11 PST -------
This is a regression from r9935 (Make sure :focus is not matched when the window is not key). Clicking in the text area makes the WebHTMLView resign as first responder, which ultimately calls setDisplaysWithFocusAttributes(false), preventing the focus selector from matching. When the window is made key again, even though the WebHTMLView is still not first responder, it calls setDisplaysWithFocusAttributes(true).

I think this can be fixed by implementing formControlIsBecomingFirstResponder methods like the formControlIsResigningFirstResponder that already exist.
------- Comment #2 From 2006-04-12 11:14:05 PST -------
Created an attachment (id=7656) [details]
Implement formControlIsBecomingFirstResponder

And another manual test...
------- Comment #3 From 2006-04-12 11:52:36 PST -------
Created an attachment (id=7657) [details]
Implement formControlIsBecomingFirstResponder
------- Comment #4 From 2006-04-12 12:47:20 PST -------
(From update of attachment 7657 [details])
Looks fine. r=me
------- Comment #5 From 2006-04-12 16:38:14 PST -------
I think we can automate the manual test included in the patch, eventSender.mouseClick for first part and layoutTestController.setWindowIsKey for the second part.