> But on re-reading the PR I see that it’s the child of the delegating node > that’s adding the dispatcher. Could you elaborate on why that is?
I guess that's just the way I made it work. Implementing this in Control is not something I've thought about a lot. > I should have asked a different question. Is the focused flag being set to > ensure the focus ring shows up? Or is it being set for some other reason and > the focus ring is an unwelcome side-effect? > > I’m trying to get a handle on what parts of the system rely on this flag > because the documentation is incorrect and the implementation is murky. For > example, the ListView and TreeView manipulate the focused flag in surprising > ways and it’s not entirely clear if this is just bookkeeping or if they’re > also trying to invoke some specific behavior in another part of the system > (like CSS). That's a good question. Let's start with the easy part: I think that tinkering with the focused flag is a bad idea. It looks like some controls do that to implement a scheme where a focused/selected cell is tracked in the context of ListView, TableView, etc. However, input focus and a "focused cell" are not the same thing, and it is confusing people: https://bugs.openjdk.org/browse/JDK-8317426 Controls should just stop doing that, and invent a new property for their "focused cell" thing. The other part of the question is whether we need nested focus flags at all. I think we probably need it because controls sometimes do certain things when they are focused. For example, TextInputControl shows a caret only when it is focused, and we want the caret to be visible if the TextInputControl is nested in another control. In general, if we want to support composite controls, where inner controls "just work", we most likely can't treat them differently than if they were top-level controls. > I don’t think a ComboBox’s editor should be focus traversable since the user > should never be able to traverse to it. Yes, good point. > I’m not sure how you would enforce these restrictions. The enabled state is a > property of Node but the editable state is not. Also a good point. > This raises another question. Can the focus delegate of the focusOwner change > dynamically? For example, what if the editor inside a ComboBox changes to an > enabled state while the ComboBox is the focusOwner? I ask because the code > that enables and disables InputMethod events queries state and needs to be > aware of changes to that state. If we extend that state to include delegates > (and I think we should) we need to know when a delegate might change. I see no reason why a control shouldn't dynamically change what it returns from getFocusDelegate(). However, there's no notification mechanism that would indicate when something has changed. Would you need something like Scene.focusOwner(), but instead of containing the outermost focused node (like ComboBox), it contains the last node in the current delegation chain (TextField)?
