Composeur : #t4x-composer-tools s'injecte dans les colonnes d'OmniChat (placeholder « Message dans ») #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Salut benros,
Petit retour de compatibilité entre Tr4ker+ (v0.30.0) et OmniChat. Un utilisateur m'a remonté un bug, et mon assistant a identifié la cause précise.
Le symptôme : la barre d'outils de composeur de Tr4ker+ (#t4x-composer-tools — Gras / Spoiler / Lien / GIF / upload) s'injecte à l'intérieur d'une colonne de chat d'OmniChat (le canal Général) et vient recouvrir mon champ de saisie. Chez moi c'est un doublon, et le BBCode ne s'applique pas à mon rendu de colonnes.
La cause : dans ensureComposerTools(), ton findComposerTA() cible textarea[placeholder^="Message dans"]. Or le composeur de mes colonnes de canaux a exactement ce placeholder (« Message dans #… »). Comme c'est un querySelector (première correspondance), il tombe sur mon textarea et t'injecte la barre dedans.
Correctif suggéré, côté Tr4ker+ : exclure les textareas qui appartiennent à OmniChat, via l'attribut de notre contrat T4CO que tu poses déjà — une ligne suffirait dans findComposerTA() / ensureComposerTools() :
js
const ta = document.querySelector('textarea[placeholder^="Message dans"], textarea[placeholder^="Message"]');
if (ta && ta.closest('[data-t4co-selfmanaged], [data-t4co-app="omnichat"]')) return; // ne pas augmenter les composeurs d'un autre script
(Mes racines portent data-t4co-app="omnichat" et data-t4co-selfmanaged — c'est précisément l'usage prévu par le contrat pour dire « ne touche pas à ma zone ».)
Pas d'urgence : je l'ai déjà neutralisé de mon côté à partir de la v7.6.34.134 qui sera mise en ligne dimanche 16/08 (je masque #t4x-composer-tools quand il atterrit dans mes conteneurs). Mais une exclusion côté Tr4ker+ serait plus propre pour tous les utilisateurs qui ont nos deux scripts, et ça évite que ta barre soit « perdue » dans mon interface au lieu de la tienne.
Merci, et bravo pour le boulot ! Bien à toi.
— Pantagruel
Salut Pantagruel,
Merci pour le rapport, et surtout pour le diagnostic : c'était exactement ça.
findComposerTA()prenait la première correspondance detextarea[placeholder^="Message dans"]dans le document, donc dès qu'une de tes colonnes précédait le composeur natif, la barre atterrissait chez toi (et la dédup ne regardait que le conteneur courant, d'où le doublon).Corrigé en v0.30.1, publiée sur le raw canonique (auto-update Tampermonkey + notre check maison via
version.json). J'ai retenu ton mécanisme T4CO, avec trois raffinements par rapport au one-liner proposé :findComposerTA()parcourt toutes les correspondances et prend le premier textarea non étranger. Lereturnsec proposé aurait désactivé notre barre sur le composeur natif de/communicationdès qu'une de tes colonnes le précède dans le DOM.[data-t4co-app]/[data-t4co-selfmanaged]dont l'app n'est pastr4kerplus(donc ça couvre aussi une future troisième app du registre, pas seulementomnichat), avec un repli sur tes racines pré-T4CO (#t9p/#t9b/.t9-col/ classet9-input) pour les utilisateurs qui n'auraient pas encore ta version taguée. Le bouton natif « Insérer une image » (qui sert d'ancre d'insertion) passe par le même filtre.#t4x-composer-toolsa déjà échoué dans un de tes conteneurs (session en cours, ancien état), elle est retirée et reconstruite à côté du composeur natif au tick d'augmentation suivant. Ton masquage défensif de la 7.6.34.134 devient donc une ceinture de sécurité plutôt qu'une nécessité.Vérifié sur 8 scénarios DOM (colonne avant/après le natif, colonne seule sans composeur natif, pré-T4CO, barre échouée, idempotence, non-régression) : la barre ne s'injecte plus que dans le composeur natif, une seule fois.
C'est précisément l'usage prévu du contrat, content de le voir servir dans les deux sens. Merci encore.
— benros