| selection in multiline Text widget [message #1857356] |
Wed, 01 February 2023 14:09  |
 Gunnar Adams
Messages: 49
Registered: May 2016 |
Member |
|
|
Hi,
we are trying to find a solution for a customer-reported "bug", which can also be reproduced in the Eclipse RAP Controls Demo:
The user reporting this wants to use the mouse to select text from a textarea which contains multiple lines with the vertical scrollbar enabled.
Whenever the selection (caret position) is scrolled out of view and the text widget does not have input focus, the following will happen:
When the user clicks in the textarea to start a text selection, the previous selection position is scrolled into view (on Edge / Chrome browsers, Firefox behaves differently), which causes an unexpected area of the text to be selected. We were able to track this down to a call on _inputElement.focus(), i.e. the current selection is scrolled into view when the textarea is focused as part of the handling of the mousedown event.
In order to reproduce this, you can set the BORDER, WRAP and MULTI properties on the Text RAP Controls demo page, set the size of the textarea to 200x100 and paste a long text (e.g. "Lorem ipsum").
Now, after selecting some text in that text area, either scroll the selected portion out of view and focus another control on the page or focus some other control on the page and then use the mouse wheel to scroll the selected portion of the text out of the visible area.
When you now try to click in the text field, you will notice, that the text will change upon mousedown and you do not hit/select the portion of the text you would expect.
Can you think of a way to apply the selection (based on mouse cursor) BEFORE textarea.focus() is called?
Thank you and best regards,
Gunnar Adams
|
|
|
|
|
|
| Re: selection in multiline Text widget [message #1857372 is a reply to message #1857368] |
Thu, 02 February 2023 11:12  |
Gunnar Adams
Messages: 49
Registered: May 2016 |
Member |
|
|
Hi Ivan,
thank you for the quick response.
Yes, activation via keyboard navigation works as expected.
The problem reported by our users only occurs when the mouse is used to apply a "selection" in an up to that point not yet focused textarea.
Imagine, that you are searching in a long text for a portion of text that you want to copy to the clipboard.
For this search it isn't required that the field has the input focus. Users can use the mouse wheel to scroll the text. When they find the text they need, they will click into the field. and expect that the text caret and/or the selection will be put in that position.
Because the browser scrolls the (previous) selection into view when the textarea is focused, users will end up with a wrong selection position.
In the above description I use "selection" as synonymous for both a caret position and an actual non-empty selection (i.e. the length of the selection does not matter).
I do not know, if it is even possible to determine and store the desired selection position (determined from the mouse position on mousedown) prior to the textarea getting the focus. I think, though, that the browser should in the default behavior of a mouse click (or mousedown) on a textarea first apply the selection and then "focus" the textarea (if it wasn't already focused). If that would be the case, the explicit _inputElement.focus() call on mousedown in the RWT framework might prevent that default behaviour.
Best regards,
Gunnar
|
|
|
|
Powered by
FUDForum. Page generated in 0.03078 seconds
] 
Search
Help
Register
Login
Home
