Direct links don't work (reliably?) if target page embeds the client

[robertknight]

We changed the way that the bouncer service (hyp.is) activates the extension and configures the extension's client to navigate to a particular annotation. This has ended up breaking direct links to annotations on target pages that embed the client.

Example bouncer link: https://hyp.is/zxCckEH4Ee6tPkNgrU9gKw/chem.libretexts.org/Courses/University_of_Arkansas_Little_Rock/Chem_1403%3A_General_Chemistry_2/Text/10%3A_Review/10.01%3A_Lewis_Dot_Structures

If you follow this link in a Chrome browser that has our extension installed, what happens is:

1. The bouncer (hyp.is) service sends a message to our extension instructing it to navigate to the target page and scroll to an annotation
2. The extension's service worker receives the message (see src/background/index.ts) and initiates the navigation
3. When the navigation completes, the extension injects configuration in the page with the details of the annotation to scroll to and attempts to activate the extension in the tab

When the target page does not embed the client, this all works fine. The problem comes when the target page embeds the client. In this case step (3) will inject configuration into the page, but the extension's client does not activate because the embedded client is already there. The embedded client meanwhile will probably not read this configuration because it was not present in the page when the embedded client initially loaded.

Some possible solutions:

• If the extension detects an embedded client in the page, have it send a message to the embedded client about the direct linked annotation (eg. via a DOM event)
• Other ideas here...

Slack thread: https://hypothes-is.slack.com/archives/C2C2U40LW/p1693313716998819?thread_ts=1692964809.673489&cid=C2C2U40LW

[janraev]

Hubspot ticket: https://app.hubspot.com/contacts/6291320/record/0-5/1855939933

[mkdir-washington-edu]

See also:

• Direct links not working properly with embedded clients product-backlog#720
• If Bouncer does not detect the Chrome extension it defaults to Via even if Hypothesis is embedded on the page support-legacy#151

[dwhly]

Could possibly add libretexts.org to bouncer's whitelist of sites that embed the client.

[janraev]

Same issue https://app.hubspot.com/contacts/6291320/record/0-5/2767399244

[dltj]

I'm probably that report immediately above:

I'm using an adaptation of Dan Whaley's DropDoc web application to generate transcripts of YouTube videos and provide a way to annotate bits of the transcript. For example, this post on Mastodon about a recent CNI briefing on JSTOR's LLM-driven bot on journal articles: https://code4lib.social/@dltj/112515330860312283. The links on that Mastodon post work fine. However, if I link to a specific Hypothes.is annotation (as I did in this Mastodon post: https://code4lib.social/@dltj/112515476692600406), the JavaScript bits that enable the reader to jump to a specific time in the YouTube recording stop working. (In other words, if you click on a transcript line in the "media.dltj.org" version of the transcript, the video player jumps to the right time. Through "via" though, it does not.) It seems like the YouTube player is not getting initialized; I see this in the console:

Uncaught TypeError: player is undefined at index.html:1847:9

Digging further, the player is defined by onYouTubeIframeAPIReady() in my JavaScript, but that function isn't being called. When I look at the page without going through Via, I see that the function is being called by a bit of YouTube's JavaScript:

• https://www.youtube.com/iframe_api

Looking at the browser console, I see that the HTTP request is getting redirected by Via to:

• https://checkmate.hypothes.is/ui/block?url=https://www.youtube.com/iframe_api&reason=media-video&blocked_for=general&v=1&sec=a06c85a70a00db30a85c167b87bba54bbd73f625a2e87120839ac7358e0f87a2

So I'm guessing that Hypothesis has blocked that bit of JavaScript. Are there any known workarounds? [Now adding: I see that there are no known workarounds. Also...the code, in all its mid-refactoring ugliness, is on GitHub.]