Double-click becomes single-click, etc. when scrollback search is focused

[injust]

Issue Description

When the scrollback search is focused, double-clicking the terminal becomes a single-click and triple-clicking becomes a double-click.

I ran into this because I had a list of words I wanted to search in succession, so I tried to:

1. Double-click the 1st word
2. cmd-f and cmd-v
3. Double-click the 2nd word
4. cmd-f and cmd-v

Expected Behavior

Double-click and triple-click should still perform their respective word/line selections, even if scrollback search is focused. I believe this is how UI focus works across all macOS apps.

Actual Behavior

Double-click becomes a single-click (selecting nothing) and triple-click becomes a double-click (selecting a word instead of a line).

Reproduction Steps

1. Open scrollback search (cmd -f)
2. Double-click or triple-click any word in the terminal

Ghostty Logs

No response

Ghostty Version

Ghostty 1.3.0-main+472b926a4

Version
  - version: 1.3.0-main+472b926a4
  - channel: tip
Build Config
  - Zig version   : 0.15.2
  - build mode    : .ReleaseFast
  - app runtime   : .none
  - font engine   : .coretext
  - renderer      : renderer.generic.Renderer(renderer.Metal)
  - libxev        : kqueue

OS Version Information

macOS Seqouia 15.7.4

Minimal Ghostty Configuration

# empty

Additional Relevant Configuration

No response

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[injust]

Note that this also happens when a split is active and you double/triple-click another split. However, that behaviour seems more correct than with scrollback search, since a split being unfocused is indicated by dimming.

[injust]

you can easily see it dims both surfaces if you have 2 splits and open a search

No it doesn't? At least not on macOS.

I think it would feel really weird if the surface dimmed when you opened scrollback search 😕

[rhodes-b]

well it gets unfocused so it makes sense that it would happen (and it does on linux)

im not sure there is going to be a easy change besides reverting the PR I linked above

I do agree it probably shouldn't do that so maybe ill put a PR up for linux (for the dimming part)

[injust]

From testing focus transfer between some random macOS apps (not terminals!), it seems like the expectation is:

• Single-click: Focuses and might propagate a click (depending on the app)
• Double-click: Focuses and propagates a double-click

Same thing applies if you click-and-drag, instead of just clicking.

[jcollie]

This was a deliberate choice in #11167 - the click that focuses a terminal should never send a mouse event to the underlying application. This is so that you can click on a terminal to focus it without worrying about where you click, for fear of inadvertently activating some action that you didn't intend. This may very well be different from how other apps (even other terminals) act, but it's the direction that we are going with for now.