Il y a souvent beaucoup, beaucoup de "inter-locks" :
- chargement de pages bloquées
- votes sans feedback pertinent/inutile et pour/contre et sans virer le lien le bouton (et ce n'est pas parce que l'on est arrivé au max/min de pertinent/inutile)
- message tribunes (rédacteurs, modérateurs, tribune de dépêche en modération) non pris en comptes
- …
Il me semble ce que ça bloque lorsque j'ai d'autres tabs ouvertes dans le même navigateur, sur LinuxFR.org. J'observe cela lorsque j'ai une autre tab ouverte, qui a un spinner/throbber qui tourne (ou pas) : la première page se chargeant quand on stoppe le spinner/throbber de la seconde.
Généralement, plus j'ai de tabs ouvertes, plus j'ai de chances d'avoir des locks.
# Scénario
Posté par Nÿco (site web personnel) . Évalué à 2 (+0/-0).
[^] # Re: Scénario
Posté par Nÿco (site web personnel) . Évalué à 2 (+0/-0).
Dans certains cas (encore non-identifiés par moi), j'ai un lock sur une tab LinuxFr, alors qu'aucune autre n'a de spinner actif. Je dois fermer une tab au hasard ou bien reloader et stopper, jusqu'à ce le lock soit releasé.
[^] # Re: Scénario
Posté par Nÿco (site web personnel) . Évalué à 2 (+0/-0).
Oui, je confirme tout cela.
Mon workaround : si une tab ne charge pas, ne poste pas dans la tribune ou ne pertinente/inutilise pas, alors je vais dans toutes les tabs ouvertes sur LinuxFr.org et je recharge, et je stoppe le chargement manuellement par Esc à la fin visible de chargement de la page, que le throbber/spinner soit actif ou non.
[^] # Re: Scénario
Posté par Bruno Michel (site web personnel) . Évalué à 2 (+0/-0).
Dans firefox, augmenter
network.http.max-connections-per-serverdans about:config permet de résoudre ce problème. Pour Chrome, je ne connais pas l'équivalent.[^] # Re: Scénario
Posté par Benoît Sibaud (site web personnel) . Évalué à 2 (+0/-0).
network.http.max-persistent-connections-per-server sur un Firefox/Iceweasel 17.0
# Une piste
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
Source : http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#notes
[^] # Re: Une piste
Posté par Mouns (site web personnel) . Évalué à 1 (+0/-0).
une idée à 2 balles impliquant :
idée :
1. n'avoir qu'un canal SSE actif par page (je précise si ce n'est pas déjà le cas)
2. utiliser localstorage comme un buffer de communication ( genre un peu comme backbone.offline ou le truc présenté par LinkedIn )
3. si aucune mise à jour depuis X seconds, tenter de "prendre la main" pour remplir localstorage
"prendre la main" signifie :
* élire un onglet qui sera le seul à faire la collecte pour les autre
* réélire un nouveau onglet collecteur si l'ancien collecteur est fermé ou a perdu sa connexion
[^] # Re: Une piste
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
FastMail a eu la même idée et la mise en pratique. Les détails sont sur http://blog.fastmail.fm/2012/11/26/inter-tab-communication-using-local-storage/. Faudrait que je creuse ça.
# Pour référence
Posté par Bruno Michel (site web personnel) . Évalué à 3 (+0/-0).
[^] # Re: Pour référence
Posté par BAud (site web personnel) . Évalué à 1 (+0/-0).
autant augmenter le PageRank de ces demandes en ajoutant ces bugs à la question initiale de Nÿco (cela sera pris en compte par le moteur de recherche de LinuxFr en plus…).
# Corrigé indirectement
Posté par Benoît Sibaud (site web personnel) . Évalué à 3 (+0/-0).
Cf https://linuxfr.org/news/communiquer-avec-le-serveur-depuis-un-navigateur-web-xhr-sse-et-websockets et en particulier le fil https://linuxfr.org/news/communiquer-avec-le-serveur-depuis-un-navigateur-web-xhr-sse-et-websockets#comment-1849831
Globalement depuis le passage en HTTP/2, ce n'est plus un souci pour LinuxFr.org
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.