@gh87 this sounds like a general UI problem rather than a search-specific problem. Can you try it out in other form elements, like the edit summary or the subject line when emailing a user?

Good news: Highlighting, i.e. double-clicking or holding down, the words is precise at edit summary and "Email this user" page. In other words, no issues in those pages.

Bad news: At search bar in the results page, the highlighting still goes to a wrong word instead of a word that I intend to target.

Any other pages that you can think of? I can think just the specific search bar.

Thanks for checking on other pages. It may be specific to the search page, but it's not really part of the main search stack, so I'm hoping some UI folks will have ideas.

Oh! What about the search box in the upper corner of the page. For better or worse, the upper corner search box and the main search bar on the search results page use different UI frameworks, so if it's only the big search bar, then we can fairly confidently tag the ticket with OOjs, too.

retested the Special:Search page on both mobile and desktop sites.

Somehow, the page's search bar in mobile appears in only smartphones, not other devices, like desktop pcs and tablets. If using a non-smartphone device, I must use the top search bar because the page's search bar isn't there. However, the top bar automatically erases the words, so I have to re-paste the words and test it myself.

The top bar and the page's bar on mobile can do highlighting almost well. However, the same issue persists on desktop site on Chrome in almost all devices.

I tested out the highlighting on iPad. Somehow, issues with the highlighting on iPad seems more complex to describe than just an issue with Google Chrome in almost all devices, especially on desktop site. I'll create a separate task about the iPad's highlighting issue. Never mind. iPad's highlighting issue is not limited to just Mediawiki but to other apps as well, so that's the issue that I can address to Apple Inc.

Borked in Chrome but seems fine on Firefox on my end (OSX desktop)

I wasn't having this problem when I first saw this ticket, but now I am. I'm also now at Version 77.0.3865.90 of Chrome.

I don't understand what's going on, but I found the direct cause of the problem: clicks are offset to the right by the amount of left padding in the search bar, as set here:

oo-ui-textInputWidget.oo-ui-iconElement .oo-ui-inputWidget-input {
  padding-left: 2.64285714em;
}

If I use the developer tools in Chrome and reduce this padding, the click offset decreases (though the text ends up behind the magnifying glass icon). If I increase the padding, the click offset increases.

I don't know if this is an OOUI problem or a Chrome problem (obviously it's the intersection of the two, but I don't know who can/should fix it), but since this is an OOUI element, I'm adding the OOUI project tag.

This issue smells very similar to T232085: RTL Wikis problem with tags in RC, history, contribs etc. in Chrome 76 and Chrome 77, with a pointer at T232085#5542281.

In T234170#5558126, @Volker_E wrote:

This issue smells very similar to T232085: RTL Wikis problem with tags in RC, history, contribs etc. in Chrome 76 and Chrome 77, with a pointer at T232085#5542281.

It feels like a different kind of issue, but it does seem like a new, slightly buggy layout engine could be the cause. I downloaded the Chrome 78 beta and it doesn't appear to have the problem anymore.

I'm removing the Search project tags because this isn't really a search-related issue, even though it happens on a search-related form element. Thanks for the report @gh87—I'm glad it turned out to be Chrome and not us!

Should we close the ticket now or wait until Chrome 78 is released (on Oct 22)?

In T234170#5561032, @TJones wrote:

It feels like a different kind of issue, but it does seem like a new, slightly buggy layout engine could be the cause. I downloaded the Chrome 78 beta and it doesn't appear to have the problem anymore.

I found the upstream issue for this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1000657, which is indeed marked as fixed in Chrome 78.

I updated to Chrome 78 today (78.0.3904.70) and all of these problems have gone away.