Recherche avancée

Sur d’autres sites (12352)

• Anomalie #4508 (En cours) : comportement erratique (et anormal) avec les table ayant des lignes av...

  11 juin 2020, par cy_altern -

  Dans un tableau si la première colonne d’une ligne est vide le rendu plante de différentes façon selon qu’il s’agit de la première ligne ou des suivantes et si le premier texte dans une cellule est dans la seconde ou les suivantes...

  Le détail à partir d’un tableau basique 3 lignes (dont une de titre) et 3 colonnes :
  

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  |bla|||
  ||||
  </span>
  Télécharger

  
  => rendu OK (table avec thead + tbody, toutes les lignes visibles)

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||bla||
  ||||
  </span>
  Télécharger

  
  => le "bla" de la 2ème cellule devient un caption qui se glisse juste après le thead , il est suivi d’un 2ème thead vide et le tbody (OK pour les tr/td) devient alors invisible même si il y a du contenu dans les cellules des lignes suivantes

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  |||bla|
  ||||
  </span>
  Télécharger

  
  => le bla disparait complètement, le thead "normal" est suivi d’un 2ème thead avec 1 ligne et 3 td puis un tbody complètement vide (même si les lignes suivantes ont des cellules avec du texte)

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||||
  |bla|||
  </span>
  Télécharger

  
  => la 2ème ligne donne un 2ème thead avec le bon nombre de th, le tbody est OK avec tr/td de la 3ème ligne

  <span class="CodeRay">|{{colonne A}}|{{ }}|{{ }}|
  ||||
  ||bla||
  </span>
  Télécharger

  
  => la 2ème ligne donne un 2ème thead avec avec le bon nombre de th, suivi par un tbody vide (ni tr,ni td)
  Idem si le bla est en 3ème cellule de la ligne (ou nième)

  Bref, il y a un sacré foirage dans l’algo de rendu de texwheel sur ce cas particulier de première cellule vide mais j’avoue que l’algo de rendu avec des regexp dans tous les sens ne m’a pas paru très "abordable" pour essayer de trouver un patch... :-(

• Anomalie #3913 (Nouveau) : Restauration incomplète d’une sauvegarde effectuée avec la même version

  27 février 2017, par Gilles Corlobé

  J’utilise SPIP 3.2.0 dev (23435).
  J’ai effectué un dump puis une restauration de ce même fichier, à quelques heures d’intervalle.
  Pendant la restauration, je surveille le contenu de la base de données avec phpMyAdmin.
  Alors que les articles avaient été restaurés, avant le step 19, les données sont corrompues : la taille ne change pas mais les données sont inaccessibles (nombre de lignes dans spip_articles = 0, taille 41.7 Mo, perte 38.4 Mo).
  Version de PHP : 7.0.15-0ubuntu0.16.04.2
  Version du serveur : 5.7.17-0ubuntu0.16.04.1
  Apache/2.4.18 (Ubuntu)

• Anomalie #3695 (Nouveau) : Édition d’un auteur et autocompletion des login/mot de passe

  13 février 2016, par tcharlss (*´_ゝ｀)

  Reproduire¶

  Voici ce que j’obtiens quand j’édite un auteur sous firefox developer edition 46, que soit un auteur existant ou un nouvel auteur (image également en pj) :
  

  Les champs login et mot de passe sont pré-remplis avec mes informations de connexion quelque soit l’auteur, par contre le mot de passe de confirmation est vide.
  Du coup quand il s’agit de mon profil, je suis obligé soit de vider le mot de passe, soit de le confirmer.
  Et quand il s’agit d’un nouvel auteur, il faut penser à changer les 2 champs.

  Solution ?¶

  Bon il n’agit pas d’un bug de SPIP, mais d’un souci dû l’autocomplétion des champ login/mot de passe des navigateurs. Et je n’ai pas constaté le problème avec les 2 autres navigateurs testés : firefox 44 normal et chromium 48.
  Si j’ai bien compris, certaines fonctionnalités de l’édition développeur arriveront à terme dans la version de base, peut-être que le problème s’y présentera aussi dans les prochaines versions.
  Donc lors de la création de mon profil, j’avais demandé d’enregistrer mes informations de connexion dans le gestionnaire de mot de passe, et maintenant il fait du zèle.
  Je ne sais pas si on peut y faire grand chose, mais au moins le problème est référencé.
  JLuc avait indiqué un rapport de bug / commentaire de commit firefox en rapport sur IRC, mais je ne retrouve pas le lien.