Search the web for the selection

Right-clicking a selection offers to search for it with whichever engine you configure. The template is parsed twice and the two origins compared, so text a remote host printed into your terminal can never turn the template into a request to a different host.

Looking up something on screen meant selecting it, copying it, finding a browser and pasting it. Upstream Tabby has no web-search action anywhere.

Right-clicking a selection offers Search the web for "…", which opens terminal.webSearchQueryURL through the platform's external-open. Windows Terminal's searchWeb is the model — but its Bing default wraps the selection in %22…%22, which this deliberately does not: the selection searches as ordinary terms.

• terminal.webSearchQueryURL: 'https://www.google.com/search?q={{query}}'

  Must be http(s) and contain {{query}}.

• The template is parsed twice and the origins compared. The selection is text a remote host printed. encodeURIComponent alone already stops it becoming a second parameter or a fragment, but the template is also probed with an inert stand-in and the result refused unless the scheme is http(s) and the final URL's origin is identical to the probe's — so it can never be turned into a request to a different host by what was selected.
• {{query}}, not Windows Terminal's %s: {{name}} is already how every URL built from matched text is written here, so there is one templating convention in the repo rather than two.
• & in a menu label is a mnemonic on Windows and Linux, so a selection of foo & bar would show as foo _bar. It is doubled for those platforms and left alone on macOS. Truncation happens before the doubling, or a cut could split a &&.
• Selections are capped at 512 characters and whitespace runs collapse to single spaces — a terminal selection can be megabytes, and a multi-line one has to search, and label, as one line.

• The source catalogue records no separate caveats for this entry. The implementation and evidence above define its scope.