2009-12-21 8 views
2

Je rencontre un comportement étrange avec Firefox et Dojo. J'ai une page html avec ces lignes dans la < tête > section:dojo.require() empêche Firefox de rendre la page

... 
<script type="text/javascript" src="dojo.js" djconfig="parseOnLoad: true, locale: 'de'"></script> 
<script type="text/javascript"> 
    dojo.require("dojo.number"); 
</script> 
... 

Parfois, la page se charge normalement. Mais parfois ce ne sera pas. Firefox récupérera toute la page html mais ne la rendra pas. Je ne vois qu'une fenêtre grise. Après quelques expériences, j'ai compris que le problème de rendu avait quelque chose à voir avec le temps de chargement du html (0). Firefox commence à évaluer la page html en le chargeant. Si la page prend trop de temps à charger le javascript ci-dessus sera exécuté AVANT que le html ne finisse le chargement.

Si cela se produit, j'obtiendrai la fenêtre grise. Conseiller à Firefox de me montrer le code source de la page affichera le code html complet correct. MAIS: si j'enregistrer la page sur le disque (Fichier-> Enregistrer sous ...) le code html sera tronquée et la partie ci-dessus ressemblera à ceci:

... 
<script type="text/javascript" src="dojo.js" djconfig="parseOnLoad: true, locale: 'de'"></script> 
<script type="text/javascript"> 
    dojo.require("dojo.number"); 
</script></head><body></body></html> 

Cela explique pourquoi je peux voir une zone grise. Mais pourquoi ce code apparaît-il ici? Je suppose que la méthode require() de Dojo fait quelque chose de "maléfique". Mais je ne peux pas comprendre quoi. Il n'y a pas d'écriture.document ("</tête > <corps> </corps > </html >"); dans le code Dojo. Je l'ai vérifié.

Le problème serait résolu, si je devais placer le dojo.require ("dojo.number"); déclaration dans l'événement window.load:

<script type="text/javascript"> 
    window.load=function() { 
     dojo.require("dojo.number"); 
    } 
</script> 

Mais je suis curieux de savoir pourquoi cela se produit. Existe-t-il une fonction Javasctript qui force Firefox à arrêter l'évaluation de la page? Est-ce que Dojo fait quelque chose de "mauvais"? Quelqu'un peut-il m'expliquer ce comportement?

EDIT: Dojo 1.3.1, aucune erreur ou avertissement JS.

+1

Avez-vous essayé d'installer Firebug et de voir comment la page se charge réellement? Aussi quelle version de dojo utilisez-vous? – Kitson

+0

En plus de regarder comment la page se charge dans le panneau net Firebug, avez-vous essayé de vérifier s'il y a des erreurs JS? – Annie

+0

Firebug m'a permis de comprendre que le timing le déclencherait. Mais il n'y a pas d'autres informations utiles. –

Répondre

0

À quoi ressemble le reste de la page? Quels éléments devraient être rendus qui ne le sont pas? Quel autre Javascript avez-vous?

Ce que vous avez l'air bien, mais vous ne serez pas en mesure d'utiliser des méthodes dans dojo.number ou toute autre chose chargée via dojo.require qu'après le chargement de la page - vous devez attendre que window.onload se déclenche, ou utiliser la méthode dojo.addOnLoad() pour déclencher un rappel. Ce dernier est en fait un peu plus rapide que l'onload. Dojo.require utilise synchroniser xhr pour charger ce qui bloque le navigateur, donc si la charge est anormalement lente, vous remarquerez un retard dans le rendu de la page.

+0

Comme je l'ai écrit, la page ne rend pas du tout. L'utilisation de méthodes dans dojo.number n'est pas le problème. Et il n'y a pas de retard dans le rendu. Firefox ne le fait tout simplement pas. –

+1

oui, mais il pourrait être utile de savoir ce qu'il y a d'autre sur la page, ou quelle est la séquence la plus simple possible pour produire ce comportement. Plus de cet extrait est nécessaire pour reproduire le problème, et une interaction doit être en jeu. – peller

0

Je pense que c'est un bug de rendu dans Firefox que j'ai vu dans un certain nombre de contextes où le facteur commun est le temps que prend le navigateur pour charger toutes les ressources chargées dans la page. Plus vous avez de scripts dans la tête qui demandent du temps sur votre réseau ou votre évaluation, plus vous avez de chances d'y être confronté. Frapper la page avec une cache chaude réduit considérablement la possibilité de rencontrer le bug de peinture. Une autre façon de l'atténuer est de mettre le javascript à la fin de la qui est également une pratique recommandée, car il n'empêche pas le navigateur de prévisualiser le balisage dès qu'il l'obtient. En ce qui concerne les spécificités de l'utilisation de dojo, les cas d'utilisation courants incluent l'exécution de choses onload comme la création et le démarrage de widgets. Si vous avez du code dans un gestionnaire onload qui utilise un module dojo comme un widget, alors collez le dojo.require l'instruction à l'intérieur du gestionnaire onload au lieu d'avant le gestionnaire onload. Il ne sert à rien de subir la pénalité de performance ou de bloquer le rendu initial de l'interface utilisateur si vous n'en avez pas besoin plus tard. Ensuite, créez des couches de dojo personnalisées pour inclure le noyau minimal (éventuellement une base personnalisée pour le rendre encore plus petit) et l'autre 90% de ce dont vous avez besoin dans un calque séparé. Chargez la couche de base minimale dans la tête (pour obtenir dojo.addOnLoad, etc), puis l'autre couche à la fin du corps. Si vous résidez dans un environnement d'application modulaire où les applications vont et viennent dans la zone de contenu de la page en fonction de la page, chaque application doit placer les instructions dojo.require pour le module dojo respectif qu'elle utilise immédiatement avant que le module ne soit référencé .

Cela ne fonctionnera évidemment pas si vous avez besoin d'un module immédiatement dans un script en ligne, mais si c'est le cas, une construction de dojo personnalisée aidera également à atténuer ce cas également.

Je ne suis pas au courant d'un problème signalé avec Mozilla, mais j'ai aussi vu cela beaucoup moins souvent sur d'autres navigateurs il y a quelques temps.

Questions connexes