Common anti-FOUC styling technique hides sidebar with `hypothesis-sidebar {visibility: hidden}`

src/annotator/sidebar.tsx の 266 行目付近にあるサイドバー要素の作成箇所と、442-446 行目の RPC 接続ハンドラーから始めます。:not(:defined) {visibility: hidden} を使用している Reddit または別のページで問題を再現し、その後、提案されている可視性またはカスタム要素に関する 2 つのアプローチのうち、どちらがクライアントに適しているかを判断します。完了とは、ホストページ側の CSS ワークアラウンドなしでサイドバーが表示されることです。

tl;dr: the sidebar is getting hidden by host page CSS rules and there are two likely easy fixes. Thanks!

Reproduction of issue
This applies to any site using some variation of :not(:defined) {visibility: hidden} CSS rules to avoid FOUCing users as dynamic custom elements load.

To reproduce:

• Navigate to https://reddit.com with some client-utilizing application (such at the Chrome plugin)
• Select some text and click Annotate or Highlight
• => Bug There is a margin shift but Hypothesis sidebar does not become visible
• Inspect the page: <hypothsesis-sidebar> has visibility: hidden

Current Impact
This makes annotating on sites that use this anti-FOUCing technique (e.g. reddit.com for social media research and teaching) impossible without a workaround.

I suspect that a version of this bug may be behind any site-by-site whac-a-mole having to do with sidebar visibility, such as #7215 . That issue impacts LMS pop-outs, so if they're related that might raise the risk/reward of trying to address this bug.
This suspicion could be confirmed by replicating any user report of invisible sidebar and looking for a :not(:defined) rule.

I recall running into something similar when I tested out Hypothesis for this use case months ago but thought it was a borked browser plugin or something.

Workaround
I'm currently working around this with a custom hypothesis-sidebar {visibility: visible} rule (via the Stylebot browser plugin) to explore using Hypothes.is for social media research. But it's a barrier to collaboration (two browser plugins and a pasted CSS rule) with non-technical colleagues and students.

Causes
This seems to be a mismatch of assumptions between the Hypothesis client and host page designers, so there are two independent causes:

1. Hypothesis client assumes no host page styles will mess with the sidebar container element's visibility
2. Any site using anti-FOUC styling based on :not(:defined) assumes that no user-relevant content will be targeted by this rule, but in our case targets the sidebar (see below for more).

Addressing either of these causes independently would likely fix most instances of this problem. Both may be straightforward fixes, so doing both would be more likely to help with any whac-a-mole invisible sidebar issues.

Cause 1 suggested fix: toggle visibility and display for sidebar

Currently, the containers' display: none is removed on RPC connect events in sidebar.tsx:442-446

    this._sidebarRPC.on('connect', () => {
      // Show the UI
      if (this.iframeContainer) {
        this.iframeContainer.style.display = '';
      }

Adding this.iframeContainer.style.visibility=''; in that conditional would make the client more robust to pages that mess with dynamic elements' visibility as an anti-FOUC technique.

Cause 2 background

Many sites use some variation of :not(:defined) {visibility: hidden} rules to avoid FOUCing users as dynamic elements load. This allows anything added to CustomElementRegistry to start invisible and be shown by downstream logic once the element's been rendered and can be laid out precisely.

Here's an example from reddit.com:

:not(:defined):not( faceplate-auto-height-animator,faceplate-dropdown-menu,faceplate-expandable-section-helper,faceplate-hovercard,faceplate-tracker ) {
        visibility:hidden;
      }

Currently, the Hypothesis client's <hypothesis-sidebar> element isn't registered with customElements.define(), which means it'll always get selected by :not(:defined).

This means that any page using :define-based anti-FOUC styling logic will leave these elements with {visibility: hidden}, as is happening here. We might call this an overly aggressive anti-FOUC approach, but it's understandable that sites would employ it if they use a lot of dynamic content. More highly dynamic content sites may choose to implement something like this over time.

Cause 2 suggested Fix: define <hypothesis-sidebar> as a customElement

In src/annotator/sidebar.ts: Replacing

      // Wrap up the 'iframeContainer' element into a shadow DOM, so it is not
      // affected by host CSS styles
      this._hypothesisSidebar = document.createElement('hypothesis-sidebar');

with

      this._hypothesisSidebar =  customElements.define("hypothesis-sidebar", class extends HTMLElement {}); 

(or some equivalent that registers it as :defined) would make the "so that" in the comment true in this case.

This change would be functionally equivalent to the current code and make this element :defined. It would thus be styled the way any other dynamic content on host pages is when there are :not(:defined) rules (anti-FOUC or otherwise).

Hope that's helpful. Sorry to be so verbose: This coulda been an "I'm feeling lucky" two line PR I suppose but today's the first day I've looked at the codebase so I kinda figured it out as I went along.