Tableau de smileys en conflit avec la base du message

[CharlesWii]

Bonjour,

Certain utilisateurs de mon forum rencontre un problème avec le placement du tableau des smileys lors de la création d’un message depuis environ 3-4 mois.

Normalement le visuel se trouve ainsi


Certain utilisateurs se retrouve avec le visuel suivant depuis une grande mise à jour (y’a environ 3-4 mois)



Vous constatez donc, que les smileys sont en conflit avec la base du message, je vous contact ainsi sur votre support d’aide pour savoir si il y’avait une solution pour résoudre le problème. Vous devez prendre note tout de même, que le problème touche pas la totalité de nos utilisateurs, seulement une petite partie d’après la publication d’un sujet qui signale le soucie.
Lien du sujet http://republique.superforum.fr/t25636-je-ne-sais-mais-vous-mais-moi#450498

En attente d’une solution, cordialement.

[Shadow]

Bonjour,

Merci pour ces explications très claires Si cela touche qu'une petite parti de votre forum il me faudrait les navigateurs qu'utilisent ces personnes et leur version.


Merci d'avance et bonne journée

[brother]

Perso, exactement le même souci depuis....un certain temps...   
Mes membres je ne sais pas,  aucune plainte de leur part jusqu'à présent...

Toujours sous Chrome (je joue avec CTRL+ALT+molette pour dézoomer afin de voir l'ensemble des smileys),
A priori je n'ai pas ce souci avec Mozilla, ni avec IE

[Shadow]

Il me faudrait la version exact de chrome svp

[brother]

Perso : Version 31.0.1650.57 m

(apparemment j'aurais une MaJ à faire)

[Shadow]

J'ai exactement la même version et je ne vois pas du tout ca

[CharlesWii]

Plusieurs utilisateurs montrent une divergence de navigateur sur la visualisation du problème, qui laisse perplexe sur son origine. Tout de même reste des possibilités que l’origine soit en prévenance de la configuration de l’écran, ou éventuellement d’une extension sur le navigateur, qui peut expliquer un décalage sur la droite des smileys.

Après analyse, je remarque que les cadres sont plus petit que la normal, l’origine du problème semble provenir de cellule rétrécie, qui ronge sur le cadrage des smileys ou vice versa. Peut-être qu’un seul code de recadrage peut résoudre le soucie,

[Shadow]

Après analyse je pense que c'est un plugin que vous avez du mettre sur google chrome

[cirederf]

Hello

J'ai le même souci sous google chrome l'affichage est comme la troisième capture d'écran du premier message que je n'ai pas avec firefox ni IE par contre ce dernier ne prend ps ma couleur de fond

Cordialement

Frédéric

[brother]

De mon côté aucune extension installée sur Chrome, après réinitialisation du navigateur pas de changement non plus...
je n'ai pas la possibilité actuellement de vérifier avec un autre ordi, car je pensais que cela pouvait venir du portable que j'utilise, notamment à cause de l'écran..?
Suis allé voir paramètre écran, rien non plus....

Au départ je pensais que cela venait aussi de mon forum, la page d’accueil est assez large, image + widget, etc... 

Au final, je file un coup de zoom + ou - et après le tableau des smilleys devient stable....

Voilà pour moi...

[Chapo]

Bonjour,

afin de vous aider à résoudre ce problème, est-ce que les personnes concernées pourraient faire 2 tests préliminaires:

• Effacer le cache du navigateur, maximiser la fenêtre puis recharger la page
  
• Pour ceux ayant des accès sur d'autres forums nous dire si sur ces autres forums le problème se reproduit
  

En effet même en utilisant Chrome 31.0.1650... je n'arrive pas à reproduire le problème, je voudrais donc m'assurer qu'il ne s'agit pas d'un problème de cache ou de style.

Nous restons à votre écoute pour vous aider à résoudre ce problème

PS: me confirmez-vous ce qu'il m'a semblé comprendre, à savoir que ce problème est arrivé en même temps que le nouvel éditeur ?

[demeter1]

Ne serait ce pas tout simplement l'iframe de l'éditeur qui est tout bonnement en position fixe ce qui fait qu'elle empiète sur les smileys en fonction de la largeur de l'écran ????

[Chapo]

Ne serait ce pas tout simplement l'iframe de l'éditeur qui est tout bonnement en position fixe ce qui fait qu'elle empiète sur les smileys en fonction de la largeur de l'écran ????

Même pas  car le problème ne vient pas de l'éditeur qui passe sur les smileys mais plutôt des smileys qui passent sous l'éditeur, de plus la colonne de gauche a une largeur suspecte.

J'ai plusieurs hypothèses et donc j'essaie de circonscrire un peu le problème avant; mais je dois avouer que votre supposition n'est pas bête ...

[***karine***]

Bonjour,


Je viens de m'apercevoir que j'ai le même problème: le cadre des smileys est décalé vers la droite.
Mais il ne date pas de si longtemps, puisque j'ai posté pas mal de messages depuis cette mise à jour, sans que ce problème soit présent.

J'utilise également chrome.



Edit: J'ai retrouvé ce problème déjà mentionné ici:
https://forum.forumactif.com/t356966-cadre-des-smileys-decale?highlight=smileys
https://forum.forumactif.com/t355530-cadre-des-smileys-decale-comment-resoudre-ca?highlight=smileys

Il semble que ce soit un problème de zoom. J'avais aussi remarqué dans mon panneau d'admin que les lettres étaient plus petites. Pourtant, je n'y ai pas touché.
Le fait est qu'il était à 90%, et qu'en le remettant à 100%, le problème a été résolu.

[brother]

Intéressant, ce problème avait déjà été évoqué...
De mon côté il me semble bien que ce souci coïncide quand-même avec les changements survenus sur l'éditeur, notamment à cause des smileys trop petits  

J'ai vidé le cache, maximiser (c'est à dire augmenter le zoom au max dans "zoom" sur Chrome?), puis rechargé la page (donc déconnexion), et là le cadre de smileys redevient stable, mais pas à tous les coups, enfin je crois  

(ma soluce pour stabiliser c'est tjrs de filer un coup de zoom avant/arrière, et là c'est ok)

Il faudrait à l'occasion que j'aille tester sur un autre forum  

[cirederf]

Hello bonjour

(ma soluce pour stabiliser c'est tjrs de filer un coup de zoom avant/arrière, et là c'est ok)

Il faudrait à l'occasion que j'aille tester sur un autre forum  

Cette astuce a fonctionné pour moi pour l'apparence sur google chrome
merci brother

[yoyolebg]

Up du sujet.

[LuxAeterna]

Salut,
C'est un problème que certains de mes membres et moi-même avons et je l'avais déjà signalé. Il est en cours de résolution : https://forum.forumactif.com/t358602-296-smiley-sous-le-cadre-reponse-quand-l-ecran-est-zoome-a-125

J'espère que le staff trouvera bientôt une solution.

Bonne soirée.

Lux'

[yoyolebg]

Salut,
C'est un problème que certains de mes membres et moi-même avons et je l'avais déjà signalé. Il est en cours de résolution : https://forum.forumactif.com/t358602-296-smiley-sous-le-cadre-reponse-quand-l-ecran-est-zoome-a-125

J'espère que le staff trouvera bientôt une solution.

Bonne soirée.

Lux'

Oui moi aussi

[lePeuple]

Bonjour,


Au retour de nos techniciens ce problème ne peut être réglé puisque c'est lorsque vous agrandissez le cadre d'édition que cela se passe. C'est donc un comportement normal du ou des navigateurs que vous utilisez. L'utilisateur a la possibilité de redimensionné son textarea pour avoir plus de confort pour écrire son contenu. C'est donc illogique que la boite des smileys se met par dessus l’éditeur et donc l'utilisateur n'a plus la possibilité de voir ce qu'il écrit.

Ce n'est donc pas un bogue  


Merci de votre compréhension et bonne journée

Je ne suis pas de cet avis. Pour moi il s'agit bien d'un bug qui intervient pour deux raisons:

- une attribution erronée d'un width de 100px au lieu de 100% sur le tableau qui contient la boîte de smiley. C'est la raison du décalage excessif sur la droite, le moteur de rendu webkit se basant sur cette largeur de 100px centrée pour fixer le bord gauche de la boîte à smiley (d'une largeur réelle de 220px). Voici le bout de code concerné (cf le width="100" sur le dernier tableau):

Code:

<table border="0" cellpadding="1" cellspacing="0" width="100%">
<tbody>
<tr><td><span class="gen" style="white-space: nowrap;"><b>Corps du message</b></span></td></tr>
<tr><td align="center" valign="middle"><table border="0" cellpadding="5" cellspacing="0" width="100">

- la création en javascript de l'iframe des smiley, ainsi que de ses dimensions. Au moment de la construction zoomée de la page webkit ne dispose visiblement pas de cette dimension de 220px de large pour l'iframe et il ne peut donc pas en tenir compte pour le calcul de la largeur de la colonne.

Code:

<div id="smileyContainer"><script type="text/javascript">function addSmileyPane() { $("#smileyContainer").html('<iframe name="smilies" src="/smilies.forum?mode=smilies_frame&amp;t=1391457482" frameborder="0" scrolling="auto" marginwidth="0" marginheight="0" height="350" width="220" class="row1"></iframe>'); }</script></div>

Pour les personnes souhaitant pallier au problème sur leur forum en attendant une réponse officielle, l'ajout de ces 2 lignes de css devrait, en principe (merci de confirmer), résoudre le problème:

Code:

#parent_editor_simple>td.row1>table>tbody>tr+tr>td>table {width:100%;}
#smileyContainer {width:220px;}

[Chapo]

Bonjour à tous,

Je ne suis pas de cet avis. Pour moi il s'agit bien d'un bug qui intervient pour deux raisons:

Moi non plus    et pour plusieurs raisons

- une attribution erronée d'un width de 100px au lieu de 100% sur le tableau qui contient la boîte de smiley. C'est la raison du décalage excessif sur la gauche, le moteur de rendu webkit se basant sur cette largeur de 100px centrée pour fixer le bord gauche de la boîte à smiley (d'une largeur réelle de 220px). Voici le bout de code concerné (cf le width="100" sur le dernier tableau):

Effectivement le width="100" est interprété comme un 100px et non 100% mais c'est une coquille présente depuis des années qui n'a jamais posé problème mais qui va être corrigée. Ceci étant si cette interprétation pose problème au niveau de l'alignement elle ne joue en rien sur le problème de largeur.

la création en javascript de l'iframe des smiley, ainsi que de ses dimensions. Au moment de la construction zoomée de la page webkit ne dispose visiblement pas de cette dimension de 220px de large pour l'iframe et il ne peut donc pas en tenir compte pour le calcul de la largeur de la colonne.

La page est construite une 1ère fois au chargement du HTML/CSS (il ne dispose pas de l'info), puis le JS vient modifier le DOM. A l'ajout de l'iframe (dans le cas qui nous concerne) le navigateur met à jour le DOM et recalcule les styles. D'ailleurs même sans modification du DOM, rien que le fait d'afficher la console produit chez moi un recalcul qui fait rentrer dans l'ordre le problème d'affichage. Heureusement que les évènements extérieurs postérieurs au chargement de la page sont pris en compte par le moteur de rendu, sinon le web serait moins dynamique.

Pour les personnes souhaitant pallier au problème sur leur forum en attendant une réponse officielle, l'ajout de ces 2 lignes de css devrait, en principe (merci de confirmer), résoudre le problème:

Code:

#parent_editor_simple>td.row1>table>tbody>tr+tr>td>table {width:100%;}
#smileyContainer {width:220px;}

En partie seulement et rien ne garantit qu'il n'y ait pas d'effet de bord, mais oui c'est déjà un bon début; c'est effectivement une solution acceptable pour la plupart des forums même si la 1ère ligne n'est pas nécessaire et que le width du #smileyContainer est en réalité un peu plus large.

En fait rajouter un hack pour un seul navigateur n'est déjà pas une solution en soit quand bien même se navigateur est dominant faute de quoi on en arrive exceptions et dérives que l'on a connu avec les IE. Cette règle est encore plus valable lorsque le problème d'interprétation du navigateur en question n'apparait que dans un contexte très particulier (zoom AV/AR).

Pour ce qui est de notre partie, nous allons corriger le problème de width="100" et nous allons tester une solution pour l'iframe des smileys. Si cette solution permet de réparer le problème sans en créer de nouveau, nous la laisserons perdurer; toutefois si elle venait à créer plus de problèmes qu'elle n'en solutionne, nous la retirerons et laisserons à chaque admin le soin de définir ses priorités en terme de compatibilité. Dans ce cas, le code fourni par @lePeuple est une bonne proposition.

[lePeuple]

Bonjour et merci pour la réponse détaillée.

En fait rajouter un hack pour un seul navigateur n'est déjà pas une solution en soit quand bien même se navigateur est dominant faute de quoi on en arrive exceptions et dérives que l'on a connu avec les IE. Cette règle est encore plus valable lorsque le problème d'interprétation du navigateur en question n'apparait que dans un contexte très particulier (zoom AV/AR).

On est tout à fait d'accord sur ce point. Mon intervention visait à donner des pistes de construction pour prévenir, si c'est possible, l'apparition du bug en question sur WebKit en mode zoom (mieux vaut prévenir que guérir ), mais je conçois très bien que cela ne soit pas une priorité vu le peu de personnes touchées.

En partie seulement et rien ne garantit qu'il n'y ait pas d'effet de bord, mais oui c'est déjà un bon début; c'est effectivement une solution acceptable pour la plupart des forums même si la 1ère ligne n'est pas nécessaire et que le width du #smileyContainer est en réalité un peu plus large.

J'avoue ne pas avoir exploré dans les détails ^^

[Chapo]

@lePeuple: disons que votre réponse est totalement correcte dans le cas d'une entraide entre utilisateurs mais que nous ne pouvons pas, nous, nous permettre de donner une solution qui risque de ne pas solutionner tous les problèmes voire d'en créer de nouveaux dans certains cas exotiques Mais merci pour votre participation et pour les propositions constructives que vous faites.

[LuxAeterna]

Bonsoir,

Pardon de taper l'incruste mais où faut-il ajouter ceci exactement ?

Code:

#parent_editor_simple>td.row1>table>tbody>tr+tr>td>table {width:100%;}
#smileyContainer {width:220px;}

Énorme merci à LePeuple d'avoir relancé ce problème, j'espère que les pistes données aboutiront sur une solution.

Bonne soirée.

Lux'

[demeter1]

Bonjour,
Tous les utilisateurs qui déclarent ce beug sont sous Chrome. Une piste à explorer vu que de nombreux soucis de compatibilité ont été déclarés sous ce navigateur.

[Chapo]

@Tous: le bug devrait désormais être résolu. S'il ne l'est pas tentez de modifier temporairement un paramètre de couleur par exemple puis faîtes un Ctrl + F5.

@demeter1: le problème de Chrome c'est qu'il fait son IE ... je m'explique: lorsqu'il y a quelques années IE avait le monopole sur le marché (quasi inexistant) des navigateurs, Microsoft se permettait de faire ce qu'il voulait et ne respectait que les standards qui ne le dérangeait pas et aux développeurs de faire avec et de créer des hacks spéciaux pour IE (voire différents pour chaque version d'IE). Chrome après des années vertueuses (sur le plan du respect des standards pas du respect de la vie privée) se met à son tour à sortir des versions obligeant les développeurs de sites web à travailler pour Chrome. Depuis la v32 par exemple il y a des problèmes de compatibilité de l'éditeur HTML avancé du PA qui jusqu'à présent a toujours très bien fonctionné, certaines spécifications HTML5 (Régions par exemple) ne seront pas prises en charges, nombreuses tentatives de remplacer le JS par des langages made in Google, ...
A titre personnel, j'espère juste que le gens prendront conscience des changements en cour sur le web (atteintes à la vie privée, au principe de neutralité, lobbying pro intégration de DRM dans les contenus web, ...) et que les éditeurs de navigateurs seront forcés par leurs utilisateurs à ne pas aller plus loin dans leurs mauvaises pratiques. J'y crois mais espère juste que ça prendra moins de temps que pour IE.

[lePeuple]

Bonjour,

Pour ma part, je constate bien la modification du width de 100% au lieu de 100 et donc le problème du décalage sur la droite est bien résorbé. Par contre je n'ai pas constaté de modification concernant le mauvais calcul de largeur au chargement de la page sur un navigateur utilisant webkit zoomé (Maxxthon 4 pour ma part, j'ai toujours eu une préférence pour les navigateurs alternatifs ) et donc le problème de chevauchement me semble toujours présent.

En regardant de plus près il semble que vous ayez ajouté ce css:

Code:

row1 div#smileyContainer{min-width:226px}

Il me semble qu'il manque juste un . pour faire référence à la classe row1 et que la modification soit prise en compte ^^ (c'est quand même assez particulier d'avoir un td de même id dans .row2 vu qu'un id devrait être unique sur la page...).

Code:

.row1 div#smileyContainer{min-width:226px}

@ LuxAeterna
Une fois le . ajouté par les dev., le bug devrait être corrigé et donc tu peux oublier le code que j'avais proposé.

[Chapo]

@lePeuple: vous avez bien raison, il manque un petit je ne sais quoi qui change tout cette fois j'ai enlevé mes moufles promis    Concernant l'ID en double, vous avez raison et ça va rentrer dans l'ordre mais ce td#smileyContainer étant là depuis un petit moment il va falloir procéder à une analyse avant suppression ou renommage.

@Tous: je confirme, ça devrait être résolu  

[LuxAeterna]

Bonsoir,

C'est effectivement résolu !!!! CHAPEAU CHAPO ! (ok elle est naze, mais le cœur y est    )

Énorme merci à toi, aux autres bidouilleurs du staff et à ceux qui ont alimenté ce topic, les conversations étaient très intéressantes.

Bonne soirée et bon week-end.

Lux'

[Chapo]

Merci @LuxAeterna mais il faut rendre à César ce qui lui appartient, c'est surtout l'intervention de @lePeuple qui a fait avancer les choses car jusqu'à présent je n'arrivais pas à reproduire le bug (donc pas non plus à voir ce qu'il fallait faire pour le corriger) et en partant de ce qu'il proposait j'ai réussi à comprendre ce qu'il y avait et reproduire la configuration générant le bug.

Bonne journée à tous