Bug 3256 – Onselect event is ignored with TEXTAREA and INPUT

• Component: Forms
• Status: VERIFIED FIXED

[Chris Petersen]

Expected Results: Onselect event should be processed on both HTML 4.0  TEXTAREA and INPUT elements
What I got: Onselect event is not processed

Steps to reproduce:

1) Open attached test case "textarea_onselect.html" in Safari 2.0
2) In the first element (TEXTAREA) , click and place carat in field. Drag a selection over all of the text and 
mouse up. No alert is displayed (onselect)
3) In the second element (INPUT), click and place carat in field. Drag a selection over all of the text and 
mouse up. Again, no alert is displayed (onselect)

[Chris Petersen]

Created attachment 2092 [details]
Sample test case that contains a TEXTAREA and INPUT element with onselect event

[Chris Petersen]

Apple Bug: <rdar://problem/4141141>

[Anders Carlsson]

Created attachment 2204 [details]
Partial fix

Here's a patch that fixes this for textareas, and puts all the necessary
machinery in place for input fields except for the actual selection
notification in KWQTextField.
The reason for it not working in KWQTextField is because the selection
notification function is called too many times, resulting in unnecessary
onSelect() calls. 
I believe the problem is that when the text field gets focus it selects
everything, causing a selection notification. Then setHasFocus changes the
selection too. I'm also getting a notification when the text field loses focus.

[Darin Adler]

I'm working to refine the patch to get it right. Some experiments with Firefox and MacIE show that:

    1) Firefox emits select events whenever you tab into an <input type=text>, even when it's empty
    2) MacIE emits select events not only when the selection changes from a range to a range and from a 
caret to a range, but also when the selection changes from a range to a caret; we'll have to keep track the 
old selection if we want to match that behavior

Need some testing with WinIE.

[Darin Adler]

Created attachment 2376 [details]
Another simple test case with both an <input type=text> and a <textarea>

[Darin Adler]

Created attachment 2377 [details]
More-complete fix

I did a more-complete fix. It seems to do everything except for the fact that
it doesn't send a selection change event when changing from a range to a caret.
We'll have to check whether WinIE sends an event in this case, and if it does,
we might have to do something more fancy, since the QTextEdit API doesn't tell
you the old selection when sending the selection change signal.

[Darin Adler]

Created attachment 2378 [details]
Slightly better test that includes 3 types of <input> as well as <textarea>

[Darin Adler]

Testing with WinIE shows that it does not do the thing that MacIE does (send an event when the selection 
becomes a caret). So I think this patch is ready to go.

[Anders Carlsson]

Thanks for looking at this. The new patch looks good to me.

[Chris Petersen]

Great ! Verified fixed with TOT Webkit (6/20) under 10.4.1.

[Joost de Valk (AlthA)]

Fixed in 10.4.2