monyi/carbon-copy

Fork 0

Feedback #22: composer de Gmail en blanco; la consola solo muestra el apps-picker de Google bloqueado #1

New issue

Open

opened 2026-11-04 17:08:44 +01:00 by monyi · 4 comments

monyi commented

2026-11-04 17:08:44 +01:00

Owner

Reportado desde el panel (reason: bugs) el 2026-11-04 15:48, tras desinstalar la 0.1.1. Texto íntegro (el formulario lo corta):

cs.js:1 POST https://csp.withgoogle.com/csp/apps-picker/v2 net::ERR_BLOCKED_BY_CLIENT
executeJs @ cs.js:1 / _saveGlobals @ cs.js:1 / init @ cs.js:1
(se repite 3 veces; la tercera copia llega truncada)

Qué es ese error

csp.withgoogle.com/csp/apps-picker/v2 es el endpoint de configuración del apps picker de Google y cs.js es su content script, no el nuestro: el de Carbon Copy compila a content-scripts/gmail.js y no aparece ni una vez en el volcado.

Diagnóstico

ERR_BLOCKED_BY_CLIENT lo emite el navegador cuando un bloqueador (uBlock, AdGuard, Brave Shields) o una extensión con declarativeNetRequest cancela la petición.
Carbon Copy no puede producir ese bloqueo: manifest.json construido con permissions: ["sidePanel","storage"], sin host_permissions, sin declarative_net_request y sin web_accessible_resources. En el repo no hay ninguna regla de red.
El endpoint responde 204 desde este VPS, o sea que no está caído: el bloqueo es local del navegador que envió el feedback.

Lo que no queda descartado

El composer en blanco podría ser coste del observer (la 0.1.1 ya lo acota a mutaciones dentro de diálogos) o algo ajeno a la extensión. Discriminante pendiente: ¿ocurre también con Carbon Copy desinstalada?

Criterio de cierre

Si el composer en blanco ocurre sin la extensión instalada: cerrar como no atribuible, dejando anotado el bloqueador del navegador.
Si solo ocurre con ella: reproducir con 0.1.1 y Pausar en Gmail, y adjuntar un perfil de rendimiento de la pestaña (DevTools → Performance, 10 s abriendo un compose).

Feedback #22

Reportado desde el panel (reason: **bugs**) el 2026-11-04 15:48, tras desinstalar la 0.1.1. Texto íntegro (el formulario lo corta): > cs.js:1 POST https://csp.withgoogle.com/csp/apps-picker/v2 net::ERR_BLOCKED_BY_CLIENT > executeJs @ cs.js:1 / _saveGlobals @ cs.js:1 / init @ cs.js:1 > (se repite 3 veces; la tercera copia llega truncada) ## Qué es ese error `csp.withgoogle.com/csp/apps-picker/v2` es el endpoint de configuración del *apps picker* de Google y `cs.js` es **su** content script, no el nuestro: el de Carbon Copy compila a `content-scripts/gmail.js` y no aparece ni una vez en el volcado. ## Diagnóstico - `ERR_BLOCKED_BY_CLIENT` lo emite el navegador cuando un bloqueador (uBlock, AdGuard, Brave Shields) o una extensión con `declarativeNetRequest` cancela la petición. - Carbon Copy no puede producir ese bloqueo: `manifest.json` construido con `permissions: ["sidePanel","storage"]`, sin `host_permissions`, sin `declarative_net_request` y sin `web_accessible_resources`. En el repo no hay ninguna regla de red. - El endpoint responde **204** desde este VPS, o sea que no está caído: el bloqueo es local del navegador que envió el feedback. ## Lo que no queda descartado El composer en blanco podría ser coste del observer (la 0.1.1 ya lo acota a mutaciones dentro de diálogos) o algo ajeno a la extensión. Discriminante pendiente: **¿ocurre también con Carbon Copy desinstalada?** ## Criterio de cierre - Si el composer en blanco ocurre sin la extensión instalada: cerrar como no atribuible, dejando anotado el bloqueador del navegador. - Si solo ocurre con ella: reproducir con 0.1.1 y `Pausar en Gmail`, y adjuntar un perfil de rendimiento de la pestaña (DevTools → Performance, 10 s abriendo un compose). Feedback #22

monyi added the

bug

feedback

labels

2026-11-04 17:08:44 +01:00

monyi commented

2026-11-04 17:41:35 +01:00

Author

Owner

Relacionado con el síntoma reportado en el chat: "si ya están puestas las cuentas, ¿para qué abrir el panel de contactos?".

La 0.1.2 cambia la inserción: la dirección se pega (evento paste con DataTransfer) en vez de teclearse. Gmail convierte una dirección pegada en chip sin abrir el autocompletado de contactos, y se elimina el caso en que una sugerencia se quedaba con el Enter y comprometía otra cuenta.

Verificado con el bundle real en Chromium (DOM con forma de Gmail, manejador de paste delegado que crea el chip): un solo paste por dirección, chip creado, campo vacío, sin repetición en la pasada siguiente.

Sigue pendiente el discriminante del composer en blanco: ¿ocurre con la extensión desinstalada?

Relacionado con el síntoma reportado en el chat: "si ya están puestas las cuentas, ¿para qué abrir el panel de contactos?". La 0.1.2 cambia la inserción: la dirección se **pega** (evento `paste` con `DataTransfer`) en vez de teclearse. Gmail convierte una dirección pegada en chip sin abrir el autocompletado de contactos, y se elimina el caso en que una sugerencia se quedaba con el Enter y comprometía otra cuenta. Verificado con el bundle real en Chromium (DOM con forma de Gmail, manejador de `paste` delegado que crea el chip): un solo `paste` por dirección, chip creado, campo vacío, sin repetición en la pasada siguiente. Sigue pendiente el discriminante del composer en blanco: ¿ocurre con la extensión desinstalada?

monyi commented

2026-11-04 17:55:18 +01:00

Author

Owner

Feedback #23: Uncaught TypeError: Cannot read properties of null (reading 'focus') en m=cm (módulo de compose de Gmail), sin un solo frame de content-scripts/gmail.js.

Ese focus() sobre null es de Gmail, pero la hipótesis es que lo provoca nuestra inserción: al revelar Cc/Bcc con un clic o al escribir mientras el usuario aún tiene el foco en el campo de destinatarios, Gmail intenta enfocar un nodo que ya no existe.

La 0.1.3 cambia tres cosas:

userIsAddressing(): no se toca el composer si el foco está en un campo de destinatarios o si hay una dirección a medio escribir (input.value no vacío). Antes el input.value contaba como destinatario confirmado y disparaba la regla a media palabra.
currentRecipients() solo cuenta chips y aria-label, nunca texto a medio escribir.
Una sola fila por pasada: revelar Cc y Bcc en el mismo tick hacía dos clics seguidos en el compose.

Verificado con el bundle real en Chromium: pasada 1 revela Cc y pega, pasada 2 revela Cco y pega, no repite; con texto en el campo de destinatarios no se crea ni el campo Cc.

Sigue pendiente el discriminante original: el compositor en blanco con la extensión desinstalada.

Feedback #23: `Uncaught TypeError: Cannot read properties of null (reading 'focus')` en `m=cm` (módulo de compose de Gmail), sin un solo frame de `content-scripts/gmail.js`. Ese `focus()` sobre null es de Gmail, pero la hipótesis es que lo provoca nuestra inserción: al revelar Cc/Bcc con un clic o al escribir mientras el usuario aún tiene el foco en el campo de destinatarios, Gmail intenta enfocar un nodo que ya no existe. La 0.1.3 cambia tres cosas: 1. `userIsAddressing()`: no se toca el composer si el foco está en un campo de destinatarios o si hay una dirección a medio escribir (`input.value` no vacío). Antes el `input.value` contaba como destinatario confirmado y disparaba la regla a media palabra. 2. `currentRecipients()` solo cuenta chips y `aria-label`, nunca texto a medio escribir. 3. Una sola fila por pasada: revelar Cc y Bcc en el mismo tick hacía dos clics seguidos en el compose. Verificado con el bundle real en Chromium: pasada 1 revela Cc y pega, pasada 2 revela Cco y pega, no repite; con texto en el campo de destinatarios no se crea ni el campo Cc. Sigue pendiente el discriminante original: el compositor en blanco con la extensión desinstalada.

monyi commented

2026-11-04 18:15:07 +01:00

Author

Owner

Captura de DevTools del usuario: la consola muestra main_gmail_auto_bcc, fn_get_state_from_local_storage: g_do_not_show_gmail_auto_bcc_splash_screen, fn_apply_index_response: rules=4 is_user_paid=false, fn_get_email_suggestions, calling update_cc_and_bcc y ThreadRowViewDriver never became ready.

Eso no es Carbon Copy: grep de esas cadenas en src public devuelve 0, el bundle no las contiene y el fichero de la traza es content.js, no content-scripts/gmail.js.

Son los logs de Auto BCC for Gmail (cloudHQ), la extensión de referencia, aún instalada con 4 reglas. Es ella la que abre el panel de contactos (fn_get_email_suggestions), llama a update_cc_and_bcc y deja ThreadRowViewDriver never became ready (compositor en blanco).

Siguiente paso: desinstalar esa extensión y probar Carbon Copy sola. Si sin ninguna de las dos el compositor sigue en blanco, el issue se cierra como no atribuible.

Captura de DevTools del usuario: la consola muestra `main_gmail_auto_bcc`, `fn_get_state_from_local_storage: g_do_not_show_gmail_auto_bcc_splash_screen`, `fn_apply_index_response: rules=4 is_user_paid=false`, `fn_get_email_suggestions`, `calling update_cc_and_bcc` y `ThreadRowViewDriver never became ready`. Eso no es Carbon Copy: `grep` de esas cadenas en `src public` devuelve 0, el bundle no las contiene y el fichero de la traza es `content.js`, no `content-scripts/gmail.js`. Son los logs de **Auto BCC for Gmail (cloudHQ)**, la extensión de referencia, aún instalada con 4 reglas. Es ella la que abre el panel de contactos (`fn_get_email_suggestions`), llama a `update_cc_and_bcc` y deja `ThreadRowViewDriver never became ready` (compositor en blanco). Siguiente paso: desinstalar esa extensión y probar Carbon Copy sola. Si sin ninguna de las dos el compositor sigue en blanco, el issue se cierra como no atribuible.

monyi commented

2026-11-05 18:02:48 +01:00

Author

Owner

Diagnóstico final (vídeo + captura de consola del 5-nov)

El log repetía leidos ... -> 0 Cc y 0 Cco pendientes con la fila Cc vacía. La lectura de "destinatarios presentes" contaba:

Valores fantasma: Gmail conserva en el input oculto de div[name=cc|bcc] lo que hubo en borradores anteriores; con chips borrados el valor sigue ahí, y la regla creía tener sus direcciones ya colocadas → no añadía nada. De ahí el "funciona a veces": borrador nuevo sin estado residual funcionaba, borrador reutilizado se quedaba bloqueado.
El alias del remitente: el escaneo de aria-label a toda la ventana cogía -alicante@lowcostparking.es del selector De.
El commit por Enter dejaba chips de texto crudo (tania@pradaautomocion.com, sin resolver) y basura de autocompletado a medias dentro del input (javi LCP maria.prada@..., la fila del final del vídeo).

Fix 0.2.2 (588fa6d):

"Presentes" = solo chips de div[name=to|cc|bcc] (atributos y su nombre accesible) y el valor de inputs visibles. Inputs ocultos y alias del De quedan fuera.
Inserción por paste (paste + clipboard): Gmail convierte una dirección pegada en chip sin abrir autocompletado; Enter queda solo como fallback, y una fila con texto a medias de una escritura anterior se limpia antes de pegar.
Solo se cuenta como añadido el chip que aterrizó (2 intentos como máximo y se rinde con log; sin bucles).

Verificado: 44 tests jsdom (los 4 nuevos codifican fantasmas/alias/basura/paste) + bundle real en Chromium con dos arneses: (a) fila Cc oculta con valores fantasma + alias del De → los 4 chips entran en <2,5 s sin tocar Para; (b) fila Cc abierta con la basura del vídeo → se limpia y entran los 2 que faltaban; cero errores y cero repeticiones.

v0.2.2 publicada (validate run 29 verde, release con asset, /updates/carbon-copy.xml ya sirve 0.2.2). El issue queda abierto hasta la confirmación de JJ en Gmail real.

**Diagnóstico final (vídeo + captura de consola del 5-nov)** El log repetía `leidos ... -> 0 Cc y 0 Cco pendientes` con la fila Cc vacía. La lectura de "destinatarios presentes" contaba: 1. **Valores fantasma**: Gmail conserva en el input oculto de `div[name=cc|bcc]` lo que hubo en borradores anteriores; con chips borrados el valor sigue ahí, y la regla creía tener sus direcciones ya colocadas → no añadía nada. De ahí el "funciona a veces": borrador nuevo sin estado residual funcionaba, borrador reutilizado se quedaba bloqueado. 2. **El alias del remitente**: el escaneo de `aria-label` a toda la ventana cogía `-alicante@lowcostparking.es` del selector De. 3. El commit por **Enter** dejaba chips de texto crudo (`tania@pradaautomocion.com`, sin resolver) y basura de autocompletado a medias dentro del input (`javi LCP maria.prada@...`, la fila del final del vídeo). **Fix 0.2.2** (`588fa6d`): - "Presentes" = solo chips de `div[name=to|cc|bcc]` (atributos y su nombre accesible) y el valor de inputs **visibles**. Inputs ocultos y alias del De quedan fuera. - Inserción por **paste** (`paste` + clipboard): Gmail convierte una dirección pegada en chip sin abrir autocompletado; Enter queda solo como fallback, y una fila con texto a medias de una escritura anterior se limpia antes de pegar. - Solo se cuenta como añadido el chip que aterrizó (2 intentos como máximo y se rinde con log; sin bucles). **Verificado**: 44 tests jsdom (los 4 nuevos codifican fantasmas/alias/basura/paste) + bundle real en Chromium con dos arneses: (a) fila Cc oculta con valores fantasma + alias del De → los 4 chips entran en <2,5 s sin tocar Para; (b) fila Cc abierta con la basura del vídeo → se limpia y entran los 2 que faltaban; cero errores y cero repeticiones. v0.2.2 publicada (`validate` run 29 verde, release con asset, `/updates/carbon-copy.xml` ya sirve 0.2.2). El issue queda abierto hasta la confirmación de JJ en Gmail real.

No labels

bug

feedback

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

monyi/carbon-copy#1

No description provided.

Rows
Columns