Global find-replace sometimes fails to respect requirement for whole word matching

[mind-bending-forks]

Does this issue occur when all extensions are disabled?: Yes

Version: 1.101.0 (user setup)
Commit: dfaf44141ea9deb3b4096f7cd6d24e00c147a4b1
Date: 2025-06-11T15:00:50.123Z
Electron: 35.5.1
ElectronBuildId: 11727614
Chromium: 134.0.6998.205
Node.js: 22.15.1
V8: 13.4.114.21-electron.0
OS: Windows_NT x64 10.0.26100

Steps to Reproduce:

Note: I am unable to give you precise instructions for reproducing this without providing code that is private, but I can hopefully provide sufficient information for you to be able to reproduce it on your own code bases.

1. Create a file (demo-bug.txt) with the following contents

if ( ! \is_array( $a, $b ) )

2. Press Ctrl+F to launch find-replace within the file. In find, enable case-sensitive and regex search, but disable whole word search. Specify the following regex to search for:

(?<!\\)(array)(?=\s*?\()

That is, occurrences of array, not prefixed by backslash, not postfixed by (maybe-whitespace)-parenthesis. The search finds one match; the word array within \is_array(. That is to be expected.

3. Alter the search settings to enable the whole-word restriction. The search should now return zero results. That is to be expected.

4. Launch global find, via Ctrl+Shift+F. Set up the search as per step 2 (without the whole-word restriction). Observe that it is finding matches in demo-bug.txt as expected, and also in other files.
   

5. Now alter the search settings to enable the whole word restriction, and refresh the search results. Observe that even though the whole word restriction is in place, it is still displaying some, but not all, non-whole-word matches:

There doesn't appear to be any obvious reason why it disregards the whole-word restriction in some files and not others. Choosing a file for which it has found an erroneous match, and repeating as a local file find shows zero results. So the bug appears to be restricted to the behaviour of global search. This buggy behaviour follows through to find-replace too, and is difficult to spot in a large list of matches, but can result in incorrect replacements, and broken code as a result.

This bug may be related to issue #251369.