- La session perdue au retour d’une sortie de veille sur le Mac ; obligé de rafraîchir pour obtenir un état correct côté administration du blog
- Les scripts bloqués lorsque l’onglet dans lequel ils tournent n’est pas actif
- Les listes déroulantes toujours aussi petites question polices ; pas glop question accessibilité
- Les champs de saisie, textarea en particulier qui capturent les accesskey positionnés sur d’autres boutons de la page et qui en empêchent du coup leur usage
- Un cache trop agressif qui m’oblige à forcer le rafraîchissement pour obtenir la dernière version de ma page d’accueil
Ça commence à faire beaucoup je trouve !
1 De stef -
Ah tiens j’ai pas ces soucis-là sous Windows ou sous linux. Change d’OS ? :)
(provoc de bon matin)
Blague à part ça doit effectivement être enquiquinant. Je vois de temps en temps Nicolas H. se plaindre aussi de la parte des onglets, je n’ai plus eu ça depuis de longues années, ouf !
2 De stef -
Ah tiens je viens de trouver WebReplay, expérience qui permet de rejouer les opérations du navigateur jusqu’au plantage. Ça te permettrait peut-être de récupérer tes onglets ?
3 De Bernard -
Sur pc (avec wamp server) j’utilise un “plug sessions” qui me permet de mémoriser des sessions pour des travaux en cours. Ainsi je peux avoir jusqu’à 15 onglets ouverts (mémorisés).
Jusqu’à la précédente version de Firefox, tous les onglets ouverts étaient chargés et actualisés en même temps; d’où captation des ressources de mon vieil ordi qui s’essoufflait… Depuis la nouvelle version (61.0.1, 64 bits), les onglets ne s’actualisent que si je les consulte; du coup, mon ordi souffle moins d’air chaud.
J’ai testé Chrome avec une extension similaire (gestion sessions). Ch’ais pu pourquoi, mais j’ai abandonné — surement parce que, à force d’utilisation régulière, on prend ses habitudes ?
Donc, pour moi, qu’un script ne tourne plus sur un onglet non actif ne me gêne pas: mon vieil ordi semble me dire merci.
Quant au cache, ouaip, j’ai remarqué que si je modifie un script il faut parfois que je réactualise plusieurs fois la page pour obtenir le résultat souhaité. A l’inverse, quand la page est recalculée ça met un certain temps — long parfois, surtout quand il doit afficher une erreur de syntaxe…
Firefox prend aussi plus de temps pour s’arrêter: il faut attendre que tous les processus FF soient fermés; parfois c’est long et pendant ce temps d’autres applis attendent avant de pouvoir être accessibles.
4 De Bernard -
De l’oeuf ou de la poule ?
Je me demande toujours qui du matériel ou des logiciels gagnera la course.
Mébon, on va pas revenir
à la chandelleaux disques souples ou cartes perforées5 De Nico -
Faut y aller fort sur le cache busting sur tes sites, ça fait du bien :)
6 De Franck -
Et pour moi c’est l’inverse, j’ai des scripts qui sont lancés à intervalle régulier (notification de nouveaux commentaires, mise en ligne de billets programmés, …) ; s’ils ne tournent qu’avec l’onglet actif, ça sert plus à rien !
7 De Franck -
Nico j’ai déjà un cache statique plutôt efficace (avec versionning des ressources js, … chargées), ça va commencer à devenir compliqué s’il faut tenir compte de chacune des spécificités d’un navigateur !
Faut-il qu’on en revienne au « Optimisé pour … » ?
8 De dascritch -
Pour le cache des scripts, en mode de développement, ce que je fait, c’est ajouter un paramètre de date qui n’est pas utilisé par le script. Exemple :
Admin.js?1234567890
Sinon, le plus simple : annule tout cache avec l’outil de dev
9 De Franck -
On utilise déjà un système équivalent pour les ressources chargées (Js, CSS, …), quant au vidage du cache via les outils de développement, même si c’est efficace, c’est un peu anti-productif en prod’, non ?