Amis du jour, bonjour!

Je rencontre quelques (gros?) soucis avec IE 6 sur un site que je développe en C# .NET 2.0 et Microsoft ASP.NET 2.0 AJAX Extensions 1.0.

Contexte:
Dans une page, j'ai un TabContainer, qui contient 5 onglets.
Pour minimiser un peu le code dans la page, je positionne donc dans ces onglets des users controls, qui embarquent avec eux leur code. Seuls dans la page principale se trouvent des boutons qui gèrent la sauvegarde en base des données présentes dans les onglets.
Ces UserControls sont construits de manière similaire: ils embarquent un UpdatePanel, avec des boutons qui servent de Trigger au refresh de l'UpdatePanel.
La logique est la suivante: on manipule d'abord les données dans les UserControls avec leurs éléments IHM (boutons...) et on sauvegarde ensuite les manipulations faites depuis les boutons de la page principale.

Problème:
Les Triggers fonctionnent très bien, les requêtes vers le server se passent sans soucis ni exception (d'abord Page_Load, puis méthode Handler du trigger, qui elle même appelle UpdatePanel.Update()...). C'est au retour du server que la réponse fait planter IE 6 (grave... j'ai une invit pour débugger IE 6 avec une instance de VS 2005... no comment ;) )...

En utilisant Fiddler (proxy HTTP listant toutes les I/O de IE), il semble que IE plante à la réception de paquets CSS le plus souvent (???) mais pas tout le temps, au retour d'une requête de refresh partiel de ma page (refresh de l'update panel).


Questions:
Est ce que le fait d'imbriquer des UpdatePanels dans des UserControls, eux-mêmes embarqués dans la page principale qui les dispatchent dans leurs onglets respectifs, peut être la source du problème?
LE BUG N'EST PAS REPRODUIT SUR D'AUTRES NAVIGATEURS (Firefox, Safari... bien que des erreurs de scripts puissent être détéctées, cela ne plantgera pas les browsers...)

Mesdames, Messieurs, au plaisir de lire vos idées/suggestions/solutions...



"Je sais que je ne sais pas" (Socrate)

Bonjour,

En quoi le fait d'avoir une invite de debug IE, fait planter IE ? Peux tu nous décrire avec plus de précision le comportement de IE ? As tu essayé de debuggé IE via l'invite de debug ? avec IE c'est ainsi que l'on s'attacher à IE afin de debugger du JavaScript.

Tu peux également regarder les résultats de ta requete via un sniffer http tel que fiddler, httpwatch, web development helper, etc ...

---

Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant

Salut Cyril,

C'est bien de toi que j'attendais une réponse, tes interventions sont tres utiles de part et d'autres sur ce que j'ai fouiné sur ce forum... j'ai retourné ton blog pour trouver des infos, mais sans succès...

C'est pas l'invit qui fait planter IE, c'est IE qui plante qui propose une invite pour le débogage JIT VS2005...
"Une exception Win32 non gérée s'est produite dans iexplorer.exe [5672]"

IE se ferme tout seul au refus de l'invite... (le process est tout simplement mort...)

Si on accepte l'invite, sans ouvrir de code source (normal) ni même de code hexa, on se prend la popup suivante:
"Exception non gérée à 0x00000000 dans iexplorer.exe : 0XC00000005: Violation d'accès lors de la lecture de l'emplacement 0x00000094".
iexplorer.exe est killé la aussi... (surveillance des process depuis ProceXP)

Il ne s'agissait pas d'un breakpoint JS... il est vrai qu'on pouvait se le demander quand je relis mon post...

J'ai ré-essayé avec Fiddler, aucune info supplémentaire que ce que j'ai marqué dans le post initial...

NB: tout se passe bien avec IE 7... ptet un peu long à la détente, mais tout passe nikel...

??

Os Court... : )
++


"Je sais que je ne sais pas"

ah effectivement si t'as une exception Win32, c'est déjà un peu plus galère.

Tu utilises un vrai IE6 ? pas un truc qui utilise plus ou moins les fichiers de IE6 comme IETester & co ? Si tu testes sur une autre machine avec IE6 ca te dit quoi ?
Tout les updatepanels plantent ? un simple HelloWorld aussi ou alors c'est ton cas particulier ?
Si c'est ton cas particulier, montre nous la réponse d'ASP.net de ta requete que tu vois via Fiddler.

---

Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant

Salut Cryil,

IE6 vrai de vrai, sp3, 6.0.2900.5512...
J'ai pu tester sur une autre machine IE 6, comportement identique.
Tous les updatePanel plantent...

ERRATUM:
Mille Confuz, je m'ai gourré dans la description de l'arborescence de mes controles. Elle est la suivante:
Page.aspx (5 onglets)
    ->UserControls métier (1 par onglet, pour alléger le code de la page principale)
       ->UserControl IHM
          ->UpdatePanel
             ->ListBoxs, Boutons
    ->boutons de validation des manip sur le user control de l'onglet concerné

Les boutons de validation des manip fonctionnent nikel, la sauvegarde en base pareil... c'est vraiment à la réception des paquets de la réponse que IE plante... y'en a un qui doit pas lui plaire

Par contre, je ne suis pas sur de comprendre ce que tu me demandes dans fiddler... : ? Dis moi si la capture présente bien les infos que tu attendais...


Ci joint les-dites captures:

Plantage IE:


Tentative debug IE dans Debugger JIT VS 2005:



Capture Fiddler:

REMARQUE:
truc bizarre que je relève en meme temps que je rédige ce post, la requête est lancée comme provenant d'un useragent Mozilla/4.0... est-ce normal?

Comme précisé dansl les premiers posts, ca plante le plus souvent à la réception d'une ressource CSS... pas la.


Je me demande si les scripts générés par ASP.NET et Ajax ASP.NET ne rentrent pas en conflit au retour d'une requete d'updatePanel...

Update:
Maintenant:

• soit je reproduis le problème (à 80%)
  

• soit l'update partiel se passe bien, comportement conforme a ce qui est attendu, par contre, je ne peux pas relancer une seconde manip ni directement des UserControls avec les UpdatePanel, ni depuis la page principale car le server me renvoie une erreur sur la validation des évènements (pageEventValidation="true"). J'imagine que c'est une valeur par défaut, car il me précise que c'est soit dans la config (web.config?) soit directement dans la page (pageEventValidation="true" dans la directive <@Page...>) et je ne trouve ces settings écrit en toutes lettres nulle part.

pour le user agent mozilla : oui c'est normal.

La capture d'écran de fiddler, ne montrent pas les appels aux updatepanels, ce surtout la réponse de ces appels qui m'interessent, tu peux voir la réponse dans la partie droite onglet response je crois.

Si tu fais un nouveau site web avec un updatepanel "Hello World" cela plante aussi ? si oui ca doit venir de la configuration du serveur, si non, il faudrais reconstruire petit à petit ta page afin de voir exactement ce qui pose problème.

---

Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant

Pour le EventValidation j'ai écrit ca : http://blogs.developpeur.org/cyril/archive/2007/01/09/validation-d-evenement-en-asp-net-2-0-eventvalidation.aspx ca explique à peu près ce qu'est la validation d'évenements et comment contourner le problème, mais ej ne pense pas que ce soit le problème prioritaire.

---

Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant

J'ai pleins de controle "maison" et j'aime bien ca !

Donc le problème est "résolu", il y a juste le problème de ton customcontrol ? As tu pu résoudre ce problème, si oui quelle était ce problème ? si non pour le résoudre il va falloir procéder de la meme facon, reconstruire petit à petit le customcontrol jusqu'a voir ce qui se passe ...
Bon courage si tu dois encore detecté ce problème.

---

Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant