On Thu, 12 Mar 2026 23:34:14 GMT, Michael Strauß <[email protected]> wrote:
> However, I see quite a bit of value of having a control not accept focus _at > all_, but still be fully functional otherwise. For example, consider a "Copy" > or "Paste" button that act on the currently focused control. It's clear that > such a button can never accept focus, as that would break the intended > function. > > With your proposed change, a button will always accept focus on click. This > subtly breaks the cut/copy/paste buttons of `HTMLEditor`: they will now steal > the focus, which removes the text cursor from the editor. This is a very interesting usecase. > There are three ways a control can receive focus Yes, other frameworks usually differ between keyboard and mouse focus. > I see two ways forward here: > 1. We could redefine focusTraversable to mean focusable, that is, whether it > can accept focus at all. > 2. If we want focusTraversable to only apply to keyboard navigation, then we > need another focusable property that can be used to prevent controls from > stealing focus. This seems like a good way. The last time I wrote about those findings, I got no answer (Me and John thought this was a bug). ------------- PR Comment: https://git.openjdk.org/jfx/pull/2106#issuecomment-4053390785
