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)
Created attachment 2092 [details] Sample test case that contains a TEXTAREA and INPUT element with onselect event
Apple Bug: <rdar://problem/4141141>
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.
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.
Created attachment 2376 [details] Another simple test case with both an <input type=text> and a <textarea>
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.
Created attachment 2378 [details] Slightly better test that includes 3 types of <input> as well as <textarea>
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.
Thanks for looking at this. The new patch looks good to me.
Great ! Verified fixed with TOT Webkit (6/20) under 10.4.1.
Fixed in 10.4.2