Description
When selecting text in a Text widget (rendered as <input> / <textarea>) by pressing the left mouse button and dragging, the selection stops being extended as soon as the mouse pointer leaves the bounds of the field. While the button is still held and the pointer is outside the field, moving the mouse no longer updates the selection; moving back into the field resumes it.
This is a regression that started with Chromium 148 (Chrome/Edge and other Blink-based browsers). It does not occur in Firefox or in Chromium <= 147.
Environment
- RAP: reproducible on the official demo, and on RAP 4.5.0.
- Browser: Chrome / Edge >= 148 (verified on 148 and 149). Not reproducible in Firefox or Chrome <= 147.
Steps to reproduce
- Open the demo "Input Widgets" page: https://rap.eclipsesource.com/demo/release/rapdemo/#input
- In a text field containing text, press and hold the left mouse button to start selecting.
- Drag the pointer outside the field bounds and keep moving.
Expected: the selection keeps extending while the button is held (as in Firefox / Chrome <= 147, and as plain native HTML inputs behave).
Actual: the selection stops updating the moment the pointer leaves the field and resumes only when the pointer re-enters it.
Root cause
RWT applies user-select: none (inline) to the <body> element. user-select: none propagates to descendants (a descendant's auto resolves to the parent's used value), so every widget element the pointer drags over computes user-select: none. Starting with Chromium 148, the engine no longer extends a text field's drag-selection while the pointer is over an element whose computed user-select is none, so the selection freezes as soon as the pointer leaves the field. (The text inside the <input> / <textarea> stays selectable regardless, which is why selecting within the field itself still works.)
Confirmed: temporarily setting document.body.style.userSelect = "text" (making the drag path selectable) restores the expected behavior on the demo.
Note: this is not limited to <body>. RWT also sets user-select: none inline on the Grid/Table's own row/cell elements, so the selection likewise freezes when dragging from a table cell editor out onto the surrounding table (and resumes once the pointer moves past the table). A fix needs to make the whole drag path selectable, not just <body>.
Description
When selecting text in a
Textwidget (rendered as<input>/<textarea>) by pressing the left mouse button and dragging, the selection stops being extended as soon as the mouse pointer leaves the bounds of the field. While the button is still held and the pointer is outside the field, moving the mouse no longer updates the selection; moving back into the field resumes it.This is a regression that started with Chromium 148 (Chrome/Edge and other Blink-based browsers). It does not occur in Firefox or in Chromium <= 147.
Environment
Steps to reproduce
Expected: the selection keeps extending while the button is held (as in Firefox / Chrome <= 147, and as plain native HTML inputs behave).
Actual: the selection stops updating the moment the pointer leaves the field and resumes only when the pointer re-enters it.
Root cause
RWT applies
user-select: none(inline) to the<body>element.user-select: nonepropagates to descendants (a descendant'sautoresolves to the parent's used value), so every widget element the pointer drags over computesuser-select: none. Starting with Chromium 148, the engine no longer extends a text field's drag-selection while the pointer is over an element whose computeduser-selectisnone, so the selection freezes as soon as the pointer leaves the field. (The text inside the<input>/<textarea>stays selectable regardless, which is why selecting within the field itself still works.)Confirmed: temporarily setting
document.body.style.userSelect = "text"(making the drag path selectable) restores the expected behavior on the demo.Note: this is not limited to
<body>. RWT also setsuser-select: noneinline on the Grid/Table's own row/cell elements, so the selection likewise freezes when dragging from a table cell editor out onto the surrounding table (and resumes once the pointer moves past the table). A fix needs to make the whole drag path selectable, not just<body>.