Bonjour,
Cette discussion fait suite à celle commencée sur un pb d'affichage de code HTML dans Joomla.
Après une recherche difficle (très peu de réponses dans les forums), le problème est localisé.
Lors du chargement de la fenêtre en cause l'évènement "onresize" est généré plusieurs fois.
Avec IE dans le cas étudié il y a quatre appels consécutifs et RAS à l'affichage.
Avec FireFox, dans les mêmes conditions au moment où l'on s'attendrait à un troisième appel à "onresize", le contenu de la textarea (.value) est vidé avant un affichage final d'une zone de texte vide.
Est ce un pb java, pourquoi ? ou Fx ?
Le caractère parfois aléatoire (affichages obtenus un certain temps ne s'exécutent plus après redémarrage de la machine) fait penser à un débordement,
Le caractère répétitif sur certaines machines semble lié au nombre d'événements générés qui ne dépend que la définition de la fenêtre (fixe) et de la taille écran.
Merci d'avance de faire avancer ce problème,
pour ma part j'ai pas mal donné et ne peut plus rien.
A bientôt.
a votre disposition pour tout renseignement complémentaire bien sur.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Crash d'affichage de fenêtre sur onresize (textarea zappée
-
Horus Agressor
- Iguane
- Messages : 887
- Inscription : 12 janv. 2006, 10:28
-
Invité
RE: Je n'ai aucun pb de code, j'informe
Bonsoir,
Le code en cause tout le monde peut l'avoir :
Joomla -> JCE-> TinyMCE/themes/advanced/source_editor.htm
Joomla -> JCE-> TinyMCE/themes/advanced/scripts/source_editor.js
du code signé de l'auteur de l'éditeur tinyMCE
Comme la fenêtre s'affiche vide pour certains utilisateur (liste de url des 8 discusions sur le sujet sur les forums), j'ai charché ce qui pouvait bien se passer.
J'ai donc pisté le pb et ce qui se passe est simple :
Source_editor ouvre un document, définit une form contenant un textarea et 4 boutons.
L'init lancé par onload assigne un texte html à doc.form.thisarea.value.
Lors du chargement l'évènement onresize exécute 2 fois une petite procédure qui ajuste la taille.
Pour tracer j'ai placé des alert dans la procédure.
Que se passe t-il :
A- avec FireFox
1- la fenêtre s'affiche encore mal taillée
2- ajustement de taille, les textes var affichent encore le nom de variable
3- nouvel évènement onresize : les même valeurs (height width que la première fois) et
4- la procédure de retaillage étant terminée, le programme étant sous le contrôle complet de l'objet document et form
Le réaffichage :
1- remplace les textes var
2- vide textxarea.value et donc affiche une fenêtre d'affichage saisie vide
Pour ne plus avoir a entendre parler du pb et comme je n'arrive pas à faire comprendre à qui que ce soit que ce n'est pas normal...
1- J'ai ajouté un bouton qui lance un alert du contenu, pour vérifier qui perd les données
2- J'ai enfin ajouté un bouton qui relit les données et les reassigne à textarea.value ce qui affiche correctement le texte souhaité
Point barre.
A noter qu'avec IE les évènements sont différents :
1- pas d'affichage du tout au départ dans le fenêtre (ni textes, ni boutons , ni textarea
2- 3 lancements de onresize pour converger (c'est le calcul qui veut ça)
3- Affichage général mais avec encore les textes var avec le nom de la var
4- Affichage des textes var
Le text-area.value reste.
Si on lit correctement mes messages on comprendra que le phénomène est reproductible et systématique sur certaines rares machines pas plus mal installées que les autres, le phénomène dsiparait parfois temporairement à la suite d'un arrêt de programme, réapparait après un redémarrage etc...
Ayant tout de même fait beaucoup de développment par le passé, j'ai déja rencontré des bugs de ce genre. En général cela a toujours été à cause d'une zone non initialisée ou d'un écrasement par débordement.
Aujourd'hui je ne suis plus compétent (et je n'ai pas le temps) d'aller au dela de ce que j'ai fait et je sais, pour mon usage, bypasser le pb.
Merci
Bonsoir.
Après ce n'est plus de mon ressort.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Le code en cause tout le monde peut l'avoir :
Joomla -> JCE-> TinyMCE/themes/advanced/source_editor.htm
Joomla -> JCE-> TinyMCE/themes/advanced/scripts/source_editor.js
du code signé de l'auteur de l'éditeur tinyMCE
Comme la fenêtre s'affiche vide pour certains utilisateur (liste de url des 8 discusions sur le sujet sur les forums), j'ai charché ce qui pouvait bien se passer.
J'ai donc pisté le pb et ce qui se passe est simple :
Source_editor ouvre un document, définit une form contenant un textarea et 4 boutons.
L'init lancé par onload assigne un texte html à doc.form.thisarea.value.
Lors du chargement l'évènement onresize exécute 2 fois une petite procédure qui ajuste la taille.
Pour tracer j'ai placé des alert dans la procédure.
Que se passe t-il :
A- avec FireFox
1- la fenêtre s'affiche encore mal taillée
2- ajustement de taille, les textes var affichent encore le nom de variable
3- nouvel évènement onresize : les même valeurs (height width que la première fois) et
4- la procédure de retaillage étant terminée, le programme étant sous le contrôle complet de l'objet document et form
Le réaffichage :
1- remplace les textes var
2- vide textxarea.value et donc affiche une fenêtre d'affichage saisie vide
Pour ne plus avoir a entendre parler du pb et comme je n'arrive pas à faire comprendre à qui que ce soit que ce n'est pas normal...
1- J'ai ajouté un bouton qui lance un alert du contenu, pour vérifier qui perd les données
2- J'ai enfin ajouté un bouton qui relit les données et les reassigne à textarea.value ce qui affiche correctement le texte souhaité
Point barre.
A noter qu'avec IE les évènements sont différents :
1- pas d'affichage du tout au départ dans le fenêtre (ni textes, ni boutons , ni textarea
2- 3 lancements de onresize pour converger (c'est le calcul qui veut ça)
3- Affichage général mais avec encore les textes var avec le nom de la var
4- Affichage des textes var
Le text-area.value reste.
Si on lit correctement mes messages on comprendra que le phénomène est reproductible et systématique sur certaines rares machines pas plus mal installées que les autres, le phénomène dsiparait parfois temporairement à la suite d'un arrêt de programme, réapparait après un redémarrage etc...
Ayant tout de même fait beaucoup de développment par le passé, j'ai déja rencontré des bugs de ce genre. En général cela a toujours été à cause d'une zone non initialisée ou d'un écrasement par débordement.
Aujourd'hui je ne suis plus compétent (et je n'ai pas le temps) d'aller au dela de ce que j'ai fait et je sais, pour mon usage, bypasser le pb.
Merci
Bonsoir.
Après ce n'est plus de mon ressort.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Le message précédent, mise au point
Bonjour,
Désolé, je ne devais pas être bien éveillé, mais je suis l'auteur (le message précédent est de moi-même.
J'avais oublié de m'identifier.
En réponse à Flore :
Je suis actuellement chef d'une entreprise de mécanique mais une assez longue expérience en informatique (toutes fonctions sauf développeur quoique 1/2 million de lignes de code en 25ans et plus aucun entraînement sérieux ailleurs qu'en VBA depuis huit ans...).
Donc je tombe sur ce pb d'affichage en mettant en route joomla pour créer un site très vite...
Je cherche... et passe beaucoup trop de temps, je suis assez têtu et quand ça me résiste...
Aujourd'hui j'ai une solution qui me convient (et n'ai plus peur d'entrer dans le code Joomla et JCE) mais je ne peux plus consacrer de temps à ce problème qui n'est à mon avis pas du tout résolu et j'essaye de passer le bébé.
Le type de problème, pour la petite histoire : roman :
Le pb majeur est que seules certaines machines semblent manifester ce phénomène mais de manière assez régulière. Il y a plus de dix ans j'ai co-développé (via messages compuserve) avec un allemand berlinois pendant deux ans un afficheur HPGL2 pour windows. Nous avons perdu un marché à cause d'un crash d'affichage qui n'arrivait que chez moi et notre client en test (Bouygues) dont 2 installations sur environ 300. Il a fallu quatre mois pour trouver, les deux machines en cause étaient les seules en 1024x768 et j'ai découvert le pot aux roses quand j'ai eu deux installations identiques face à moi, l'une fonctionnant l'autre se plantant. Dans notre ca&s je suis en 1920 x 1200 et je viens d'y penser...
Peu de temps avant c'est Fortran qui ne mettait pas à blanc un index de record à l'open de file en accès direct, crash assuré si la zone contenait une valeur invalide, sinon parfois totalement aléatoire, évidemment cela dépendant de ce qui s'était passé avant mais n'avait rien à voir quand aux causes réelles (discours sur la causalité...), etc...
A bientôt
Bien solidairement
Trebly
Nota : le vouvoiement n'est pas une marque de distance mais une habitude que j'ai du mal a contrer au moins tant que je n'ai pas échangé des courriers plusieurs fois, même si je me sens très solidaire et proche de votre communauté.
Evidemment je vous enverrai si vous le souhaitez le code en cause et mes ajouts[/i]
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Désolé, je ne devais pas être bien éveillé, mais je suis l'auteur (le message précédent est de moi-même.
J'avais oublié de m'identifier.
En réponse à Flore :
Je suis actuellement chef d'une entreprise de mécanique mais une assez longue expérience en informatique (toutes fonctions sauf développeur quoique 1/2 million de lignes de code en 25ans et plus aucun entraînement sérieux ailleurs qu'en VBA depuis huit ans...).
Donc je tombe sur ce pb d'affichage en mettant en route joomla pour créer un site très vite...
Je cherche... et passe beaucoup trop de temps, je suis assez têtu et quand ça me résiste...
Aujourd'hui j'ai une solution qui me convient (et n'ai plus peur d'entrer dans le code Joomla et JCE) mais je ne peux plus consacrer de temps à ce problème qui n'est à mon avis pas du tout résolu et j'essaye de passer le bébé.
Le type de problème, pour la petite histoire : roman :
Le pb majeur est que seules certaines machines semblent manifester ce phénomène mais de manière assez régulière. Il y a plus de dix ans j'ai co-développé (via messages compuserve) avec un allemand berlinois pendant deux ans un afficheur HPGL2 pour windows. Nous avons perdu un marché à cause d'un crash d'affichage qui n'arrivait que chez moi et notre client en test (Bouygues) dont 2 installations sur environ 300. Il a fallu quatre mois pour trouver, les deux machines en cause étaient les seules en 1024x768 et j'ai découvert le pot aux roses quand j'ai eu deux installations identiques face à moi, l'une fonctionnant l'autre se plantant. Dans notre ca&s je suis en 1920 x 1200 et je viens d'y penser...
Peu de temps avant c'est Fortran qui ne mettait pas à blanc un index de record à l'open de file en accès direct, crash assuré si la zone contenait une valeur invalide, sinon parfois totalement aléatoire, évidemment cela dépendant de ce qui s'était passé avant mais n'avait rien à voir quand aux causes réelles (discours sur la causalité...), etc...
A bientôt
Bien solidairement
Trebly
Nota : le vouvoiement n'est pas une marque de distance mais une habitude que j'ai du mal a contrer au moins tant que je n'ai pas échangé des courriers plusieurs fois, même si je me sens très solidaire et proche de votre communauté.
Evidemment je vous enverrai si vous le souhaitez le code en cause et mes ajouts[/i]
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Le problème avec ce genre de frameworks plein de couches c'est qu'il est difficile de dire qui est responsable du non affichage final.
Cela peut être dû à une supposition incorrecte sur le déclenchement de certains évènements dans Gecko, que ce soit concernant l'ordre dans lequel ils se produisent ou l'état de la page à ce moment-là. Par exemple, si l'évènement onresize en question fait appel à une requête XMLHttpRequest, l'ordre des évènements peut être tout à fait différent selon que le résultat est déjà en cache ou non.
En tout cas, je dirais que le déclenchement de plusieurs onresize est une mauvaise utilisation des ressources du navigateur. La disposition et les dimensions des éléments devrait être assurée par la feuille de style de la page, et éventuellement modifiée une seule fois quand le redimensionnement est terminé.
Cela peut être dû à une supposition incorrecte sur le déclenchement de certains évènements dans Gecko, que ce soit concernant l'ordre dans lequel ils se produisent ou l'état de la page à ce moment-là. Par exemple, si l'évènement onresize en question fait appel à une requête XMLHttpRequest, l'ordre des évènements peut être tout à fait différent selon que le résultat est déjà en cache ou non.
En tout cas, je dirais que le déclenchement de plusieurs onresize est une mauvaise utilisation des ressources du navigateur. La disposition et les dimensions des éléments devrait être assurée par la feuille de style de la page, et éventuellement modifiée une seule fois quand le redimensionnement est terminé.
♫ Li tens s'en veit, je n'ai riens fais ;
Li tens revient, je ne fais riens. ♪
Li tens revient, je ne fais riens. ♪
Affichage d'une textarea d'une form environnement joomla
Bonsoir,
J'ai mis pas mal de temps à pourvoir répondre et surtout apporter du contenu au sujet.
Quelques remarques préliminaires pour clarifier les circonstances (mais finalement sans intérêt majeur quant au problème d'origine) :
1- il n'y pas de css autre que part défaut (une pop up avec 4 boutons et une textarea)
2- il y a, en tout, 6 instructions html comprenant 2 appels javascritpt (hors utilisation de variables pour le texte multilingue des boutons) de 5 lignes (l'un affectant le contenu de la textarea, l'autre calculant la taille fort correctement.
3- les resize sont générés par l'objet "form" :
a- un premier resize suivi d'un affichage automatique contenant les "noms de variables" javascript au lieu (pas encore) de leur valeur
b- un resize suivi d'un réaffichage avec les contenus des variables
et ça, le développeur (html, php, javascript) n'y peut rien.
Au premier resize l'affichage de la textarea est bon au deuxième c'est la textarea qui a été vidée, il n'y a pas de problème de réaffichage proprement dit le contenu à afficher étant devenu vide.
Je pense pouvoir affirmer que le problème est (comme je le pensais précédemment) bien en amont. En effet après avoir constaté que, dans le template utilisé pour le site joomla, il existait des incongruités et redondances (sans erreur de syntaxe réelle vue par dreamweaver ou nvu et autres, mais des héritages à priori conflictuels en particulier), leur correction fait disparaître le problème (c'est à dire que le contenu .value de la textarea n'est plus mis à "null" de manière intempestive).
Je pense donc à un problème d'interprétation de css douteux qui générerait un débordement. Car sinon comment expliquer que le déchargement d'autres programmes de la mémoire fasse que "ça passe".
Un jour par hasard on trouvera un "truc" dans le code, ou bien une réécriture partielle de code fera oubliér définitivement ce problème qui a tout de même empoisonné l'existence de cinq ou six utilisateurs de joomla et contiuera probablement de manière épisodique un certain temps à rendre la vie difficile à d'autres.
A bientôt
Bien cordialement
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
J'ai mis pas mal de temps à pourvoir répondre et surtout apporter du contenu au sujet.
Quelques remarques préliminaires pour clarifier les circonstances (mais finalement sans intérêt majeur quant au problème d'origine) :
1- il n'y pas de css autre que part défaut (une pop up avec 4 boutons et une textarea)
2- il y a, en tout, 6 instructions html comprenant 2 appels javascritpt (hors utilisation de variables pour le texte multilingue des boutons) de 5 lignes (l'un affectant le contenu de la textarea, l'autre calculant la taille fort correctement.
3- les resize sont générés par l'objet "form" :
a- un premier resize suivi d'un affichage automatique contenant les "noms de variables" javascript au lieu (pas encore) de leur valeur
b- un resize suivi d'un réaffichage avec les contenus des variables
et ça, le développeur (html, php, javascript) n'y peut rien.
Au premier resize l'affichage de la textarea est bon au deuxième c'est la textarea qui a été vidée, il n'y a pas de problème de réaffichage proprement dit le contenu à afficher étant devenu vide.
Je pense pouvoir affirmer que le problème est (comme je le pensais précédemment) bien en amont. En effet après avoir constaté que, dans le template utilisé pour le site joomla, il existait des incongruités et redondances (sans erreur de syntaxe réelle vue par dreamweaver ou nvu et autres, mais des héritages à priori conflictuels en particulier), leur correction fait disparaître le problème (c'est à dire que le contenu .value de la textarea n'est plus mis à "null" de manière intempestive).
Je pense donc à un problème d'interprétation de css douteux qui générerait un débordement. Car sinon comment expliquer que le déchargement d'autres programmes de la mémoire fasse que "ça passe".
Un jour par hasard on trouvera un "truc" dans le code, ou bien une réécriture partielle de code fera oubliér définitivement ce problème qui a tout de même empoisonné l'existence de cinq ou six utilisateurs de joomla et contiuera probablement de manière épisodique un certain temps à rendre la vie difficile à d'autres.
A bientôt
Bien cordialement
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
salut,
poste un bug(==>) et mets-y en attachement le code correct pour les css
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
poste un bug(==>) et mets-y en attachement le code correct pour les css
Message envoyé avec : Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
jaim.at-
Invité
Re : poster bug et css correct et dev. pour template joomla
Salut,
Bien d'accord, mais pour confidence j'ai réécrit plus de 70% du css du template (libre - joomlabox auteur jean luc Marius 10/2005) à la fois à cause de comportements non adéquats, mais aussi parce que j'ai ajouté pas mal de styles pour la mise en page des contenus et l'aide à l'administration des mises au point et corrections.
Tout est bourré de commentaires et le problème est celui du temps car mon job c'est tout de même d'être chef d'entreprise (secteur ingénierie et industrie), et faire un travail propre demande du temps que je n'ai pas du tout actuellement.
Le template modifié me sert pour le développement du site que sera accessible vers la fin du mois. et le temps est ce qui me manque le plus.
Alors donner le code correct sans explications sur l'effet... ce n'est pas mon genre, ne pas discuter avec l'auteur avant serait très incorrect.
Donc je reviendrai sur cette discussion, c'est promis, mais dans un certain temps
A bientôt
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Bien d'accord, mais pour confidence j'ai réécrit plus de 70% du css du template (libre - joomlabox auteur jean luc Marius 10/2005) à la fois à cause de comportements non adéquats, mais aussi parce que j'ai ajouté pas mal de styles pour la mise en page des contenus et l'aide à l'administration des mises au point et corrections.
Tout est bourré de commentaires et le problème est celui du temps car mon job c'est tout de même d'être chef d'entreprise (secteur ingénierie et industrie), et faire un travail propre demande du temps que je n'ai pas du tout actuellement.
Le template modifié me sert pour le développement du site que sera accessible vers la fin du mois. et le temps est ce qui me manque le plus.
Alors donner le code correct sans explications sur l'effet... ce n'est pas mon genre, ne pas discuter avec l'auteur avant serait très incorrect.
Donc je reviendrai sur cette discussion, c'est promis, mais dans un certain temps
A bientôt
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
-
Invité
Soluce pour écrans vides (facile...)
Pour les problèmes d'affichage du code HTML pour les éditeurs WYSIWYG dans JOOMLA, voir http://www.tm4y.co.za/joomla-tips/wysiw ... blems.html.
De mon coté (problem 1), je faisais référence dans mon navigateur à localhost, dans le fichier configuraion.php à 127.0.0.1...
Il faut peu de chose !
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
De mon coté (problem 1), je faisais référence dans mon navigateur à localhost, dans le fichier configuraion.php à 127.0.0.1...
Il faut peu de chose !
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Re: Affichage de code HTML - Joomla JCE-TinyMCE
Bonjour,
J'ai consulté l'article en référence.
Il fait une synthèse fort intéressante en sachant que 90% de défaillances citées voient leur orgine dans des url erronnées aux causes multiples ou des anomalies d'installations. Sans être vraiment expert j'en conseille la lecture tout en sachant que le problème qui fait l'objet du présent sujet n'y est pas actuellement référencé.
A bientôt.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
J'ai consulté l'article en référence.
Il fait une synthèse fort intéressante en sachant que 90% de défaillances citées voient leur orgine dans des url erronnées aux causes multiples ou des anomalies d'installations. Sans être vraiment expert j'en conseille la lecture tout en sachant que le problème qui fait l'objet du présent sujet n'y est pas actuellement référencé.
A bientôt.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Qui est en ligne ?
Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité