The way click to focus works causes visual glitches on various Widgets

[ZandevOxford]

Have you checked closed issues? https://github.com/Textualize/textual/issues?q=is%3Aissue+is%3Aclosed

Please give a brief but clear explanation of the issue. If you can, include a complete working example that demonstrates the bug. Check it can run without modifications.

When you click on a Widget which doesn't have focus, then it gets given focus and the on_focus handlers get called before any of the mouse events get triggered, and indeed isn't dependent on the mouse event being delivered.

This is a problem because the Widget can't tell why it has been given focus. This leads to various visual glitches.

For example, if you click in the middle of a TextArea which does not have focus, then the cursor is briefly drawn at the end of the text before appearing where you clicked. Another example is ListView, where if you have a list view without focus where the action is to close the screen, then clicking on an item (other than the first) in the ListView will never show it as highlighted before it is destroyed.

It will be helpful if you run the following command and paste the results:

textual diagnose

This doesn't seem to work for me with the current Textual, but that's a separate issue.

[davep]

This doesn't seem to work for me with the current Textual, but that's a separate issue.

This would suggest you've not installed devtools.

[TomJGooding]

For example, if you click in the middle of a TextArea which does not have focus, then the cursor is briefly drawn at the end of the text before appearing where you clicked.

I can't seem to reproduce this issue, could you possibly share a screen recording of what you are seeing?

text-area-click-focus.mp4

from textual.app import App, ComposeResult
from textual.widgets import Button, TextArea

TEXT = """I must not fear.
Fear is the mind-killer.
Fear is the little-death that brings total obliteration.
I will face my fear.
I will permit it to pass over me and through me.
And when it has gone past, I will turn the inner eye to see its path.
Where the fear has gone there will be nothing. Only I will remain."""


class ClickFocusApp(App):
    def compose(self) -> ComposeResult:
        yield Button()
        yield TextArea(TEXT)


if __name__ == "__main__":
    app = ClickFocusApp()
    app.run()

[TomJGooding]

Another example is ListView, where if you have a list view without focus where the action is to close the screen, then clicking on an item (other than the first) in the ListView will never show it as highlighted before it is destroyed.

Wouldn't you need a short delay before closing the screen to give the user chance to observe the selection? Something like this:

from textual import on
from textual.app import App, ComposeResult
from textual.screen import Screen
from textual.widgets import Button, Label, ListItem, ListView


class ExampleScreen(Screen):
    def compose(self) -> ComposeResult:
        yield Button()
        yield ListView(
            ListItem(Label("One")),
            ListItem(Label("Two")),
            ListItem(Label("Close this screen"), id="close-screen"),
        )

    @on(ListView.Selected)
    def on_list_view_selected(self, event: ListView.Selected) -> None:
        if event.item.id == "close-screen":
            self.set_timer(0.2, self.dismiss)


class ClickFocusApp(App):
    def on_mount(self) -> None:
        self.push_screen(ExampleScreen())


if __name__ == "__main__":
    app = ClickFocusApp()
    app.run()

[davep]

Another example is ListView, where if you have a list view without focus where the action is to close the screen, then clicking on an item (other than the first) in the ListView will never show it as highlighted before it is destroyed.

I suspect this is one of those places where you'd use call_after_refresh. For example, see how this looks:

from textual import on
from textual.app import App, ComposeResult
from textual.widgets import ListView, ListItem, Label

class ListViewMenuApp(App[None]):

    def compose(self) -> ComposeResult:
        yield ListView(
            ListItem(Label("Beep"), id="beep"),
            ListItem(Label("Close"), id="close")
        )

    @on(ListView.Selected, item="#beep")
    def do_beep(self) -> None:
        self.bell()

    @on(ListView.Selected, item="#close")
    def do_close(self) -> None:
        self.exit()

if __name__ == "__main__":
    ListViewMenuApp().run()

vs this:

from textual import on
from textual.app import App, ComposeResult
from textual.widgets import ListView, ListItem, Label

class ListViewMenuApp(App[None]):

    def compose(self) -> ComposeResult:
        yield ListView(
            ListItem(Label("Beep"), id="beep"),
            ListItem(Label("Close"), id="close")
        )

    @on(ListView.Selected, item="#beep")
    def do_beep(self) -> None:
        self.bell()

    @on(ListView.Selected, item="#close")
    def do_close(self) -> None:
        self.call_after_refresh(self.exit)

if __name__ == "__main__":
    ListViewMenuApp().run()

[ZandevOxford]

Hmm. I concur that that simple example doesn't show the visual problem.

I suspect the issues I'm seeing are due to the focus causing a redraw in my app, then processing the mouse afterwards. I'll have to see if I can come up with a sensible reproduction case.

[TomJGooding]

@ZandevOxford Did you manage to resolve this in your app? It is difficult to help without a reproducible example - please do close this if no longer an issue.

[ZandevOxford]

Sadly I've not had the time to investigate in detail.

I've had a quick look with textual 0.58.1 and note that I don't see this issue when running from the Mac terminal directly, but do see it in the Visual Studio Code editor.

My suspicion is that this might be regarded as an extremely minor bug in textual (in that I think it puts the cursor at the wrong position very briefly), but it's probably not visible in most terminals, and probably only visible in VS Code due to a quirk of how it does the updates.

Feel free to close this. I'll submit another one if I ever see a case where is causes something more serious than a brief flicker in VS Code.