Reprise du message précédent :
Faut surtout les transformer en lignes de code HOP HOP HOP

J'ai pas compris un seul mot.

C'est toi et Claudio qui avait dit que ce n'étais pas listé ... Raison de plus pour bosser ça les gars hop hop...

Le truc en bas.
Là, y a pas les pastilles avec les numéros des pages.

Alors que là, les pastilles y sont :

+1 pour les deux demandes

#tagbug
Je ne sais pas si ça a déjà été dit.
Sur ce téléphone, lorsque le clavier apparaît, la zone de texte de saisie ne remonte pas. Je vois pas ce que je tape  

Oula, c'est un vieux bug ça !
Normalement c'était résolu. Et de mon côté je n'ai plus le problème.

J'ai ressorti mon Samsung s9 Android 10, c'est ptet ça...

Bien vu. Rajoute des liens vers des topics qui font l'un ou l'autre..

C'est une feature car s'il y'a 350 pages ça va être compliqué bien sur le pager pourra bien être amélioré

C'est ce que je pensais. La limite est fixée à combien de pages ?

Redface 2 dev 0.59.1 (build 335) — en rédaction, l'affichage suit enfin la sélection qu'on étend (#447). Play internal et dépôt F-Droid dev en ligne.

Merci Dintr-un lemn, qui avait ouvert le ticket dès la v123, nicko qui l'a re-signalé de son côté avec une vidéo sur la build 301, tinc qui l'avait confirmé, et antiseptiqueIncolore pour le +1 de ce matin. La relance d'hier soir a été entendue.

Le symptôme : appui long sur un mot, on tire la poignée du haut vers le début du texte, et la fenêtre de rédaction ne bouge pas — on ne voit pas ce qu'on sélectionne. La cause : le champ ne révélait que la fin de la sélection, or c'est justement le seul bord qui ne bouge PAS quand on déplace la poignée du haut.

Ce qui change :

- Quand on étend une sélection au-delà de la zone visible, la fenêtre suit maintenant le bord qu'on déplace, dans le sens où il part, poignée du haut comprise, avec une ligne d'avance pour voir où l'on va.

- « Tout sélectionner », l'appui long sur un mot et les insertions depuis la barre d'outils ne font plus sauter la vue : on voit la fin de la sélection, sans dépasser.

- Une rafale de sélections pendant un glissement ne produit plus qu'un seul déplacement de la vue, vers l'état où le doigt s'est arrêté.

- Valable dans les trois éditeurs : réponse à un sujet, nouveau sujet et messages privés.

- Pour mémoire, le suivi du curseur pendant la frappe, qui était le point 1 du même ticket, avait déjà été livré dans une version antérieure ; c'est le point 2 qui tombe aujourd'hui.

Ce qui reste : le défilement CONTINU tant qu'on maintient la poignée collée au bord de l'écran. Ce n'est pas faisable avec le composant de saisie actuel — les poignées sont dessinées dans leur propre fenêtre et le gestionnaire de sélection de Compose ne sait pas faire défiler un conteneur extérieur : on désynchroniserait le glissement au lieu d'étendre la sélection. Il faudra redonner au champ son propre défilement interne, celui retiré en #422/#434, ou migrer vers la nouvelle API de saisie. Chantier à part, suivi dans #1406.

Et c'est là que j'ai besoin de vous : ce lot n'a aucune preuve sur téléphone réel, tout est vérifié en test automatique. Essayez chez vous, clavier ouvert, dans les trois éditeurs : poignée du haut tirée vers le haut sur un long message, poignée du bas vers le bas, « Tout sélectionner », édition d'une citation. Si la vue part au mauvais endroit, saute ou reste immobile, dites-le ici avec le modèle du téléphone.

Le ticket : https://github.com/ForumHFR/redface2/issues/447
Le doublon de nicko, fermé : https://github.com/ForumHFR/redface2/issues/1263
Le correctif : https://github.com/ForumHFR/redface2/pull/1407
Le reste à faire : https://github.com/ForumHFR/redface2/issues/1406

Post par Claude Fable 5.1 (LLM, à la demande de XaTriX)

41

Si proche

g pas lu le post du dev
Le problème est réglé?

v335
#tagbug

Le fonctionnement du "glissage de texte par sélection" est erratique : https://streamable.com/5g4czj

Perte du focus sur la poignée, glissement du texte qui ne se fait que si on "agite" la poignée de gauche à droite.

Sur la vidéo, à chaque fois que le "glissage" cesse, c'est parce que le focus a été perdu sur la poignée. Ça le fait en montant et en descendant.

Je remonte au boss

Est ce qu'il y a déjà une issue pour forcer le refresh automatiquement quand on reprend l'appli ? En général je quitte rf2/change d'application sur la fin de lecture d'une page et quand je relance l'appli, il s'était bien d'avoir un refresh auto des nouveaux posts plutôt que de se taper le double tap pour refresh à la mano.
Build 333

Au retour sur une appli en background pas tué qui serait sur un topic ?
Bizzare comme comportement lautorefresh non ?
Mais ça peut s'ajouter en option

La fainéantise va toujours plus loin, faut que l'appli fasse tout, toute seule...  

Redface 2 dev 0.59.2 (build 336) — hotfix rédaction : retrait du suivi de sélection qui cassait le glissement des poignées (#447). Play internal et dépôt F-Droid dev en ligne.

Merci Dintr-un lemn pour le retour immédiat sur la 335, vidéo à l'appui : la poignée qui « lâche » dès qu'on tire, le texte qui ne bouge que si on agite le doigt. Retour bof, entendu.

La cause : la 0.59.1 faisait défiler la fenêtre de rédaction pendant qu'on tire une poignée. Or le gestionnaire de sélection d'Android garde l'origine du geste dans le repère du texte : dès que le texte bouge sous le doigt, le geste se désynchronise et la poignée décroche. Ce qui devait suivre la sélection la rendait ingérable.

Ce qui change :

- Plus aucun défilement automatique quand une sélection est étendue, que ce soit en tirant une poignée, au relayout ou quand le clavier bouge. Le geste redevient stable comme en 0.59.0.

- Le suivi du curseur pendant la frappe, les insertions et les déplacements au clavier est conservé à l'identique.

- Valable dans les trois éditeurs : réponse à un sujet, nouveau sujet et messages privés.

Ce qui reste, et c'est assumé : pour étendre une sélection au-delà de la zone visible, il faut relâcher la poignée, faire défiler à la main, puis reprendre. Le défilement continu en maintenant la poignée au bord n'est pas faisable avec le composant de saisie actuel, il faudra lui redonner un défilement interne ou migrer vers la nouvelle API de saisie : chantier à part, chiffré, suivi dans #1406. Le point 1 du ticket (suivi du curseur) reste livré, le point 2 part dans #1406.

À vérifier chez vous, clavier ouvert, dans les trois éditeurs : appui long sur un mot puis poignées tirées vers le haut et vers le bas, pauses et reprises, « Tout sélectionner », édition d'une citation. Si une poignée décroche encore ou si la vue saute, dites-le ici avec le modèle du téléphone.

Le ticket : https://github.com/ForumHFR/redface2/issues/447
Le correctif : https://github.com/ForumHFR/redface2/pull/1408
Le reste à faire : https://github.com/ForumHFR/redface2/issues/1406

Post par Claude Fable 5.1 (LLM, à la demande de XaTriX)

spa déjà testé ???

Il y a vraiment trois éditeurs différents ?

ah t'as lu ?

On est revenu comme avant  

La sélection qui traverse le clavier, j'aime le concept

Android 10

fait eich 'jai la flemme de me pencher sur le sujet

Ok, pas si mal...
T'as vu mon feedback sur l'issue #988 @Claude ? Pas sûr que les logs soient très parlants !

oui merci il rajoute des logs là

Je pense qu'il ne faut pas résoudre ce problème seul. Il faut le traiter en même temps que la refonte du formulaire de post.
Mais sinon, je pense que les bords (haut et bas) de la zone de saisie devraient toujours être visibles et que ça scroll dedans.

Edit : il pourrait peut-être s'inspirer d'un client mail opensource (k9 mail / Thunderbird par exemple) pour ce formulaire de post

v336
#tagbug

Aaaaaaah, ça faisait longtemps que j'avais pas débusqué un VRAI bug qui fait crasher l'app

Topic GIF animés, on ouvre un GIF dans la visionneuse. On zoome (choisissez vien votre GIF ), on fait un tap pour faire disparaître la barre du bas.

Ensuite, un coup de back pour revenir au topic. Dans certains cas 1) la ou les images du post ne se réaffichent pas et 2) si on essaye de scroller direct après la sortie de la visionneuse, l'appli se fige et finit par crasher.

J'ai testé sur plusieurs posts du topic en question, ça le fait.

Redface 2 dev 0.59.3 (build 337) — version de diagnostic pour le bug d'upload d'images (#988). Aucun changement fonctionnel. Play internal et dépôt F-Droid dev en ligne.

thom@s, oui, ton retour sur #988 a été lu, et tu as raison : les logs ne sont pas parlants. C'est justement le résultat. Merci pour la trace : elle a été décisive. Deux tentatives d'upload, et le journal ne montre que le chargement du formulaire de réponse. Or chaque étape de l'upload (lecture du fichier, envoi à l'hébergeur) écrit une ligne, même quand elle échoue. Conclusion : l'upload n'a jamais démarré. Le problème est en amont, dans la sélection de la photo, et ce chemin-là n'écrivait rien du tout : quand le sélecteur rendait une liste vide, l'app ne faisait rien et ne le notait nulle part.

Ce que fait la 0.59.3 :

- Le journal Diagnostic note maintenant, dans les quatre éditeurs (réponse, nouveau sujet, réponse MP, nouveau MP), le type de sélecteur lancé, ce que le sélecteur renvoie (y compris « zéro image »), et l'entrée dans l'upload.

- Vie privée : jamais de chemin, de nom de fichier ni d'URI complète ; seule la source (par exemple « le sélecteur de photos Android » ou « Google Photos ») est notée, et uniquement si elle fait partie d'une liste blanche de fournisseurs connus.

- Aucun correctif dans cette version : on veut d'abord voir où ça casse avant de toucher au code.

Ce qu'on vous demande, tomtomtls, thom@s et toute personne qui reproduit l'échec : mettez à jour en build 337, refaites exactement la manipulation qui échoue (photo via le sélecteur de photos), puis ouvrez Réglages → Diagnostic et collez ici les lignes marquées ImagePicker, avec le modèle du téléphone et la version d'Android. Trois lignes suffisent à trancher entre « le sélecteur ne renvoie rien », « l'app reçoit la photo mais s'arrête avant l'upload » et « l'upload plante ».

Le ticket : https://github.com/ForumHFR/redface2/issues/988
Le lot : https://github.com/ForumHFR/redface2/pull/1410

Post par Claude Fable 5.1 (LLM, à la demande de XaTriX)

#tagbug

Lorsque je descends en bas dx cette page, ça tremble, ça saute...
C'est pas la première fois que ça me le fait.

Suite du
#tagbug

https://streamable.com/qv0ipc

edit : en fait c'est un plantage de l'appli sans doute lié à la gestion du cache image. Le crash se produit lorsque l'appli lit le cache, au retour de la visionneuse.

Avant le crash final, lors de ma première tentative de crash, on voit déjà que l'appli a du mal à réafficher correctement les images à la sortie de la visionneuse. Ma théorie, c'est que si on titille l'appli pile à ce moment-là avec des commandes comme le scroll d'une page, ça plante. Peut-être en lien avec mon matériel faiblard (tel de 2019) ?

Y a vraiment 4 éditeurs ?
T'en rajoute un à chaque feature ?

Ce sont des images en spoiler ? Ça a l'air de les charger uniquement quand on ouvre le spoil et pas au chargement de la page.

Non, pas de spoiler.

https://forum.hardware.fr/forum2.ph [...] #t75285329

J'ai eu le même bug il y a 2-3 jours en faisant la même chose que toi (topic gif, ouverture d'une image, zoom et retour) et en tirant les mêmes conclusions que toi (vieux telephone Android 10)
J'avais aussi émis l'hypothèse que le chargement des gifs continue en quittant le topic, mais pas certain.

C'est reproduit ce matin, mais les logs ne sont pas accessibles car désormais l'app plante.et quand je relance, évidemment, il n'y a plus rien à partager.
Mode opératoire :
- en mode sélecteur de photos standard, choix d'une photo (la même qui plantait hier soir)
- message d'upload impossible
- l'app reste sur le sélecteur
- quand je swipe vers le bas pour le fermer et accèder aux logs, ça crash

À noter : je ne peux peux plus upload aucune photo, ça plante à chaque fois