Reprise du message précédent :
là c'est un géographe le mec à l'autre bout ...

Demande lui de virer son antivirus pour voir..

Suffit qu'il ait un anti-Ads/Popups/Banners et qu'un de tes fichiers JS s’appelle genre "banner.js" => bloqué par l'antivirus si ses regexps sont trop restrictives.

Testé et approuvé ya pas longtemps

je vais voir, mais ça serait bizarre, car son collègue a le même anti-virus.

La version de IE8 c'est *exactement* la même ?
Parfois t'as un patch MS qui est appliqué sur un poste et pas un autre, qui change une version mineure et paf.

ouais, je l'ai entendu me réciter les 2 numéros de version dans le téléphone.
 

 
Ça marche avec un autre navigateur sur le poste incriminé ?
Les configurations proxy sont les mêmes ?
Si le mec dont l'IE 8 "fonctionne" se logue sur le poste incriminé, ça passe ?
Vous servez tout avec le même domaine ?

j'ai demandé à un collègue de prendre le relais sur le truc, je suis cramé.  
 
Je vais utiliser les idées de l'accès à distance et de la source de la page et ensuite c'est mon collègue qui prendra le relais (on a aussi un pb de perf).

oui pour l'autre navigateur (firefox, mais pas déployé au niveau corporate),  
oui pour le proxy (sauf s'ils ont de l'équilibrage de charge avec des sessions sticky et une merde dans le cache de mon client, mais pourquoi FF fonctionnerait ?),  
c'est des laptops et je sais pas s'ils ont des profils à distance, je vais voir
oui, et la même VM en-dessus.

 
T'embête pas à vérifier le coup des sessions user, je pensais à un éventuel profil d'utilisateur différent (genre l'un est sur whitelist, l'autre non), mais le test du navigateur différent sur le même poste lève le point.
Pour le coup du domaine, j'ai pas compris ton histoire de VM. Ma question (pas forcément claire) était de savoir si l'intégralité de votre contenu était servi par le même domain.tld. Genre savoir si il n'y a pas un JQuery servi par Google ou une siouxerie dans ce genre.

la réponse exacte est non (because y'a au moins un énorme google maps au milieu de l'écran)
mais dans le code, tout est protégé, si google maps se charge pas, tout le reste marche, tu peux ouvrir l'appli dans le train (c'est un truc que je fais assez souvent), t'as une interface normale avec un trou blanc à la place de la map (après un timeout de 2min quand même)

OK.
 
Peut-être une dernière piste. Si la conf proxy est faite à partir d'un script pac, à l'ouverture de session, le browser va sélectionner sa conf proxy selon le type de user.
 
Dans ce cas et selon le contenu de votre script, tu peux avoir un bout de la balance de charge à ce niveau.
 
Chez nous (lolcorp@300k user aussi), la dernière ligne, donc le match par défaut, renvoi vers la sélection d'un des miroirs proxy parmis la liste complète, le choix étant fait en fonction de la charge courante de ceux-ci. Si le poste tombe sur un proxy fucké (rétention ou je sais pas quoi), ça peut expliquer le truc.
 
Si t'es dans ce cas, tu peux toujours afficher le proxy courant du poste kivabien avec un about:config et l'entrer en dur dans le poste fucké, en bypassant la conf pac.
 
My two cents.

ok, thanks, je suis bourré, et le client dors, mais je vois ça demain, si j'arrive à avoir un accès direct à sa machine, je peux tenter des trucs.
 
merci, je crois que ça relance un peu mon affaire.

Dites voir,
 
Je voudrais une table, avec un nombre de colonnes variable, scrollable en largeur s'il y a trop de colonnes.
 
Si je mets la table dans un DIV, avec un overflow: auto; sur le site, et une largeur fixe sur la table (genre 1000px), ça marche.
 
Sauf que je ne veux pas fixer la largeur de la table... Je veux qu'elle s'adapte au contenu..

Sur la table ?
 
Ça ne va rien changer, elle ne dépassera jamais la largeur du conteneur.
 
En gros, si mon conteneur fait 800px de large, et que ma table (en fonction de son contenu) doit faire 600px, elle fera bien 600px.
 
Par contre, si la table est censée faire 1000px de large (par exemple avec 10 colonnes fixées en CSS à 100px), et bien elle ne va faire que 800px (taille du conteneur) et les cellule vont faire 80px chacune (alors qu'elles sont fixées à 100px via la CSS)

Pour illustrer mon propos :
 
http://jsfiddle.net/ByScripts/hNG9Y/

Bon je viens de trouver.
 
Il faut mettre un "width: 100%" et un "table-layout: fixed" sur la table.
 
(Et fixer la largeur des cellules.)

J'ai un soucis d'encodage d'une requête ajax.
Sous Firefox les accents dans le json passent bien mais sous Chrome j'ai le droit à des "Téléphone".
La page est affichée en UTF-8 et il semblerait que la méthode $.ajax de jquery force l'envoie en utf-8.
 
Des idées ?

la réponse de retour doit aussi être en UTF-8

Même si on ne se sert pas de la réponse ?
Parce que dans le profil réseau le json envoyé a déjà des soucis d'accents, alors que sous Firefox c'est nickel.

Voici la trame sous Chrome :

Firefox :

Content-Type:text/plain;charset=ISO-8859-1

Je ne comprends pas en quoi l'encodage de la réponse influe sur l'encodage du json envoyé au contrôleur, et encore moins pourquoi l'encodage est bon sur firefox mais pas sur chrome.

Ba c'est du texte. Tu dis "heÿ, je t'envoie du ISO-8859-1" alors que le truc en face il comprend de l'UTF-8 ; à un moment ça foire. En l'occurrence c'est les accents.
Après, la différence Chrome/Firefox se fait peut-être parce que vous ne renvoyez pas explicitement l'encodage du content-type et que le browser va avoir un comportement par défaut différent. Vu que les accept sont les mêmes, je pense pas que ce soit côté serveur que ça diffère, mais mate quand même les headers côté serveur histoire de voir que les réponses sont les mêmes.

EDIT : ah mais nan, c'est ton serveur Apache Coyote qui spécifie un Content-Type différent à chaque fois, non ? 'tain c'est le bordel ton truc.

Koskoz > laisse moi deviner: t'as pas mis de filtre qui spécifie le charset dans ton web.xml. J'ai bon?

 
je developpe une appli chez un client,
impossible de le faire en appli access, je suis donc parti sur une appli web,
et comme la DSI bride tout de partout, je fais tourner un serveur wamp portable stocké sur le poste client, qui vient taper dans un .mdb sur le reseau pour les données, et sur le reseau pour tout ce qui est :
 
- js
- images
- css,
 
il n'y a en local donc que le wamp et les fichiers php/html,
 
ca tourne sans soucis sous IE7, avec des liens sous la forme :
 
\\RESEAU\COMMUN\xx\xx\style.css
 
mais rien sous FF, notion de securité je pense,
c'est possible de faire ca sous FF ?

ca marche sous IE, mais FF ne charge rien, tout en silence,
 
je pense qu'il ne veut pas afficher des données locales sur du "en ligne", car en copiant collant, ca passe.

 
Nan mais c'est du grand n'importe quoi. Si c'est une appli web, dans ce cas, tu fais la db sous mysql, le site tu le dev en php, mais ce que je ne comprends pas, c'est pourquoi tu as des liens CSS sous cette forme moche que tu nous montres. Normalement les CSS et autres resources doivent être appelées en HTTP, et être relatives à la page ou en absolu (/css), mais doivent être appelées en http.
 
Et cette appli devra être hébergée sur un serveur, et ce n'est pas une DSI qui vient pleurer pour monter une simple instance web sur un apache, ils doivent bien avoir un serveur avec apache dans le coin, il n'y aurait juste qu'à rajouter un vhost

 
Je suis dans une filiale d'un grand groupe, avec une DSI centralisée, et si on fait une demande pour un serv apache + vhost + mysql, ca sera fait, mais dans 8mois.
C'est donc un honteux bricolage, qui suffit pour le nombre d'utilisateurs concernés (8 personnes, environnement maitrisé).
 
Le jour ou ils sont ok pour un apache + mysql, je migre tout, change mon PDO, et ca marche.
 
Donc pour le moment, pas le choix, je dois faire comme ca!

, donc pourquoi ne pas heberger temporairement l'appli sur une des machines et faire en sorte qu'elle tourne toujours.
8 mois pour un simple serveur avec vhost, c'est du beau foutage de gueule.
Si l'appli ne tourne que pour 8 personne pourquoi demander un serveur dédier alors que tu peux monter un vhost sur un serveur existant ?
C'est chelou.

A mon taf pour avoir une maquette ou une instance, ça prendre 2 minutes à demander et on l'a dans l'heure voir la journée maximum tout dépends de la charge de travail de nos barbus.

pour le serveur sur une des machines, c'est possible, mais completement interdit (deja eu un cas comme ca, le type s'est prix un blame...).
 
Et oui, c'est completement du foutage de gueule, ca doit etre approuvé par mon N+1, +2, et +3 que je ne connais meme pas,  
une fois approuvé, ca fait l'objet d'études de réalisations, ...
 
Ca à mis 6 mois à deployer access sur 8 postes, alors que le packe office pro 2007 etait deja installé, donc juste un composant de plus quoi
 
Donc bon, pas trop le choix que de faire comme ca, malheureusement.
 
J'aimerais bien leur louer un dedié, y mettre mon appli, et pouvoir faire quelque chose de tres stable, mais je n'aurais pas acces au serveur de fichier (emails, documents), donc bloqué aussi.
 
J'oubliais : le mdb est en partie justifié, des macros outlook y stockent certaines données necessaires à mon appli.

Et pour le fait de servir mes fichiers statiques (js, css, img) sur le serveur :
 
je pourrais les mettre en local, mais ca fait moins de choses à MAJ, et surtout j'ai d'autres fichiers à servir (documents, .eml, ...) donc je ne peut pas tout mettre en local, autant les laisser sur le serveur.

 
Si ton accès réseau a une lettre de lecteur associé, la syntaxe qui fonctionne avec FF est

Si tu as des espaces / caractères spéciaux dans le path, pense à URL encode.
 
Edit BBCode

nraynaud, t'as trouvé d’où venait votre bug bizarre au fait ?

Normalement il a une lettre, mais au choix de chaque user, je peut donc faire un parcours de chaque lettre en php avec un is_dir sur mon dossier pour détecter la lettre mais ça me plaît pas trop dans la mesure ou si un nouveau arrive, sans avoir monté le serveur sur une lettre, il ne trouvera rien.
Pour ff, je voulais voir si c'était jouable de trouver un format d'adresse universel (ie, ff, chrome, ...) pour être un poil plus carré, mais c'est tout, on se passera de FF.

Et espérer que le comportement actuel de IE soit toujours valable sur les prochaines versions, quand la dsi mettra à jour !

j'oubliais : la demande d'un serveur sera refusée par la dsi car on a un service national pour les besoins d'applis / outils, mais qui réponds au demandes aussi en 8mois ... Et ils n'aiment pas trop la concurrence, donc en gros ma mission n'est pas très "officielle", et ne doit pas l'être.

et après, ils pourront dire : vous voyez que vos applis achetées hors DSI sont nulles : elle ne supporte pas la moindre maj

Ma Cogip a bien mis 4 ans pour débrancher une webappli obsolète ('cause nouvelle version), alors bon...

quand je vois des DSI aussi moisis que ça et avec des délais aussi à chier que ça, je ne suis même pas étonné que certaines boites coulent comme le Costa Concordia.