Plantage IE UpdatePanel dans un UserControl

Résolu
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008 - 26 août 2008 à 13:10
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008 - 1 sept. 2008 à 12:10
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)

10 réponses

cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008
29 août 2008 à 14:13
Salut,

Bon, alors après reconstruction étape par étape, tests unitaires, j'ai pu localiser mon problème:
J'utilise (c'est pas forcément un choix ; ) un composant de type gridview enhanced avec des fonctionnalités telles que le filtre en haut de chaque colonne, du regroupement d'entrées.... un peu comme des infragistics... sauf que c'est fait "maison"... (je sais...)

Bref, il semble exister des incompatibilités avec les updatePanels: le cas basique d'un refresh de cette grid via le refresh d'un update panel, le tout directement dans une page (cad sans embarquer l'update panel contenant la grid dans un UserControl lui même embarqué dans une page) plante IE (la fameuse exception win32 non gérée). IE doit recevoir des lignes de code, a priori CSS ou JS, qui le font planter sans tir de semonce (un peu comme cette fameuse ligne HTML qui a les mêmes effets: check http://poleweb.blogspot.com/2007/08/une-ligne-cssxhtml-plante-ie-6.html).

Par contre, le souci dans mon code a moi était que tout mes update panel etaient en mode UpdateMode="Always". Du coup, les refresh des UpdatePanel qui ne contenaient pas la grid view provoquaient forcément le refresh du panel qui contient la GridView... d'oû exception a chaque refresh de chaque update panel.
J'ai passé tous les UpdatePanel en UpdateMode="Conditional", de manière à ce que seul le panel concerné par un trigger (bouton, ddl...) soit rafraichi.

Du coup, en fait, plus de problème... juste un composant "maison" (avec les inconvénients qu'on sait) qui faisait tout planter ; )

Merci pour ta dispo,
Au plaisir
3
jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
26 août 2008 à 18:56
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 ...

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
0
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008
26 août 2008 à 19:22
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"
0
jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
26 août 2008 à 19:34
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.

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008
27 août 2008 à 13:44
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...
0
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008
27 août 2008 à 14:18
Update:

Maintenant:
<li>soit je reproduis le problème (à 80%)
</li><li>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.</li>
0
jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
27 août 2008 à 19:11
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.

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
0
jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
27 août 2008 à 19:16
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.

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
0
jesusonline Messages postés 6814 Date d'inscription dimanche 15 décembre 2002 Statut Membre Dernière intervention 13 octobre 2010 29
29 août 2008 à 15:26
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.

<hr />Cyril - MVP ASP.net - MCPD ASP.net & MCTS SQL - Consultant indépendant
0
cs_will48 Messages postés 6 Date d'inscription mardi 13 mars 2007 Statut Membre Dernière intervention 1 septembre 2008
1 sept. 2008 à 12:10
Hélas non, je n'ai plus la main sur le composant "maison"... ou plus exactement "fait main" mais par d'autres mains que celles de la maison justement (freelance).
Du coup, "support" au petit bonheur la chance et suivant disponibilité (...), et je souhaite bien du plaisir aux gens "de la maison" pour maintenir tout ca le jour ou le fournisseur de ce composant ne sera plus de la partie... c'est dommage, il y a plein de bonnes idées pour ce composant (vraiment), mais une GridView qui ne propose pas d'accesseurs pour itérer sur ses rows, c'est quand meme regrettable, voire fâcheux...

Donc les composants maison, volontiers, quand ils ont été éprouvés, documentés, et pis avec un minimum de cohérence... c'est bien d'ajouter des fonctionnalités dans tous les sens, mais si ca coûte les principes de bases, je préfère autant m'en passer... (ceci n'engage que moi)

CCL: qui peut le plus peut le moins: ben c'est la première fois que je vois quelque chose qui ne suit pas ce bon vieil adage (sans doute pas la dernière... ; )

Au plaisir d'échanger à ce sujet... mais ce n'est sans doute plus l'endroit pour ca : )
Encore merci
0
Rejoignez-nous