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

Abierto
  • ¿Algo no está bien?
#7,498 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
javascript
Área
frontend

Línea de trabajo

Empieza en src/annotator/sidebar.tsx, cerca de la creación del elemento de la sidebar en la línea 266 y del handler de conexión RPC en las líneas 442-446. Reproduce el problema en Reddit o en otra página que use :not(:defined) {visibility: hidden} y determina cuál de los dos enfoques sugeridos sobre visibilidad o custom elements encaja con el cliente. Se considera terminado cuando la sidebar se hace visible sin un workaround de CSS en la página host.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Mustache
Estrellas
743
Forks
227
Merge medio
6 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hypothesis/client

Todos los issues de hypothesis/client

Issues similares

Más issues de Web Dev

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.