On Firefox the H tooltip gets activated on ctrl + f highlights

[kelseym-ai2]

Steps to repro:

1. Use firefox bookmarklet OR go somewhere the H is already installed (e.g Semantic Reader)
2. Hit "ctrf + f" and type something in. Anywhere there's a term match highlighted, the H tooltip pops up, which is quite distracting.

This issue was originally reported by a Semantic Reader user.

URL: https://www.semanticscholar.org/reader/060ff1aad5619a7d6d6cdfaf8be5da29bff3808c

[robertknight]

Can you provide a link to the Semantic Scholar page you are testing with? I was not able to reproduce with Firefox 111's built-in PDF viewer, but I could reproduce on an ordinary web page (https://example.com).

The Hypothesis tooltip appears whenever a text selection is created within the content, as reported by window.getSelection(). The reason we do this rather than respond to eg. mouse events is to be agnostic of what input method (keyboard, mouse, commands from screen reader etc.) the user used to create the selection. Chrome and Safari do not modify the selection when using the "find in page" feature, but it seems that the current Firefox version does.

If we could identify when the selection has been created by the find-in-page feature then we could avoid showing the Annotate/Highlight toolbar. We must be careful not to break the ability of the toolbar to be triggered by keyboard, touch or assistive technology-created selections though.

[kelseym-ai2]

I added the URL for the screenshot-ed page in the issue description.

I found the same thing as you did, this is reproducible on any regular webpage in Firefox. I believe the PDF rendering library we use is somehow rendering text behind the scenes (I will ping someone from our engineering team to describe this better).

This sounds great if possible:

If we could identify when the selection has been created by the find-in-page feature then we could avoid showing the Annotate/Highlight toolbar. We must be careful not to break the ability of the toolbar to be triggered by keyboard, touch or assistive technology-created selections though.

[undfined]

Hey @robertknight thanks for looking into this. Sounds like you've landed on the same conclusion regarding the cause. Just wanted to reiterate that the S2 Reader falls into "ordinary webpage" in this context :) My hunch is it's going to be quite difficult to determine the caller of window.getSelection() reliably. Curious to see what you all come up with.

[robertknight]

It turns out this is actually a feature for screen reader users on Windows. When reviewing and "selecting" text in the most popular screen readers, JAWS and NVDA, the selection actually happens in an off-screen virtual copy of the document, and is thus not visible to web applications. Hence selecting text in a way that allows you to annotate it is not easily possible. This behavior in Firefox allows a workaround by opening the find dialog and searching for the text that you want to annotate.

A proper solution for this issue is being worked on (see https://github.com/hypothesis/client/issues/5924), but this workaround is actually functional today.

[robertknight]

Unfortunately there is nothing I can see in the selectionchange event itself that differs depending on whether find-in-page or another method was used. One difference I do see is that when selectionchange events are triggered by the find-in-page feature, document.hasFocus() returns false at the point when the event is received, since the focus is on Firefox's find bar. If mouse or keyboard events are used on the page, then document.hasFocus() returns true. I'm not sure what the status of focus will be if selecting text using a screen reader (eg. VoiceOver or NVDA's new "native selection" feature).

I note that the page mentioned in the original report, https://www.semanticscholar.org/reader/060ff1aad5619a7d6d6cdfaf8be5da29bff3808c, does not appear to use Hypothesis any more, but the basic issue can be reproduced on any web page in Firefox.