Conservation du scroll vertical après un Save

Emmanuelle · January 28, 2026, 2:13pm

Request description

Bonjour,
Depuis cette évol, la position dans l’écran est conservée quand on quitte et revient sur un formulaire.

J’ai l’impression que ça ne s’applique pas quand on fait un Save ou tout autre bouton d’action, car le focus est déplacé sur le bouton. Est-ce bien le cas ? Car j’ai peut-être des choses spécifiques qui contrarient la fonctionnalité.
Si oui, serait-ce possible de garder la position aussi en cas de clic sur bouton ?

Merci d’avance !

[Platform]
Status=OK
Version=6.2.21
BuiltOn=2026-01-15 22:16

PS : nous sommes en train de tester la 6.3

Francois · January 29, 2026, 9:27am

Bonjour,

Le fonctionnement est que le focus et le scroll vertical sont mémorisés dans la nav afin d’être replacés si possible, car rien ne garantit que les choses seront encore là/habilitées suivant le contexte de l’objet/des droits au moment de l’affichage.

On avait remarqué des pb de comportement quand la page met du temps à s’afficher / le scroll était positionné trop tôt. En 6.3 ça a dû être amélioré avec une promesse finale qui attend que tout le monde soit là pour remettre le focus et le scroll.

A priori le bouton “save” n’a pas de règle particulière. Il reprend bien le focus et le scroll est remis sur le container. Tu peux essayer de mettre de points d’arrêt pour voir ce qu’il se passe dans ton contexte, tu sembles avoir l’habitude de le faire :

Simplicite.UI.Navigator

leave : mémorise à la sortie du container le focus et le scroll
restore : essaye de les remettre quand la nav y revient

Emmanuelle · January 29, 2026, 9:48am

Oui j’avais en effet fureté dans ces méthodes mais comme mon Save est appelé dans du code front je pense que je suis sur un cas particulier. Je vais réinstaller mon projet sur une 6.3 pour voir si ça se reproduit, si oui je me lance dans le débug.

Merci de ton retour, je reviendrai poster les infos.

Emmanuelle · February 3, 2026, 2:56pm

Bonjour,

J’ai fini par identifier d’où vient mon problème : j’ai codé un reload dans le onload
C’est un bricolage car le Save de mes objets inlined recalcule un pourcentage d’avancement sur l’objet père, je force donc un reload pour avoir ce pourcentage à jour.

Mais le restore est appelé après le reload, donc à mon 2ème reload, on n’a pas encore fait le premier Restore et on est encore en haut de l’écran.

            onload && onload();
            ui.getNav(ctn).restore(ctn);

Y a-t-il un autre hook que je pourrais utiliser après le restore pour mon deuxième reload ? Ou une meilleure façon de gérer mon pourcentage ?

Merci !
Emmanuelle

Francois · February 4, 2026, 9:27am

Dis comme ça la boucle infinie n’est pas loin…

Normalement il n’y a rien à faire car le bouton “save” du formulaire est une promesse qui fait :

le save du parent
puis le save de chaque objet inliné
puis le reload du formulaire (sauf si erreur pour les afficher)

cf controller.saveForm(ctn, obj, params) si tu veux debugger ce que fait la promesse.

Donc à priori au reload, le parent reçu est à jour si le calcul est bien synchrone en back.

Emmanuelle · February 4, 2026, 10:03am

Oui j’ai utilisé un param de session pour ne le faire qu’une fois après un Save.

Mon souci est le suivant, au Save :

Save du parent
Save des enfants qui déclenche un calcul du pourcentage parent
Reload du form avec le pourcentage du parent avant calcul

Avec mon double reload, je récupère bien le parent recalculé.

Francois · February 9, 2026, 2:05pm

Je ne comprends pas pourquoi le select “final” ne ramène pas les données à jour sur le parent mis à jour juste avant ?

En front :

Peux-tu voir les requètes ajax passer dans le bon ordre ?
Il me semble que le front séquence bien les appels par promesses succéssives.

En back :

Essaye de mettre des traces pour voir qui passe en premier postSave du fils / postSelect du père.

Emmanuelle · February 9, 2026, 2:17pm

Dans le postSave de mes objets inlinés, j’ai un select sur le parent avec calcul d’un champ puis Save. Je pense que ce calcul n’est pas terminé au moment du reload donc j’ai encore la V1 du parent.
Ca ne devrait pas être le cas ?

Francois · February 10, 2026, 4:11pm

Le front attend le retour de chaque save via promesses avant de faire le reload du parent.
D’où mes questions pour savoir dans quel ordre les choses se passent réellement vu du navigateur ajax+ des hooks appelés.

En 6.2

	return new Promise((ok,ko) => {
		// Save main form first (to get Id in case of creation)
		ui.saveObject(ctn, obj, null, params)
		.then(m => { // ok
			if (m)
				msgs = msgs.concat(m);
		})
		.catch(e => { // ko
			if (e)
				errs = errs.concat(e);
		})
		.finally(_ => {
			// Save inlined 0,1 links
			return links();
		})
		.then(_ => {
			$view.hideLoading();
			if (!errs.length)
				errs = null;
			if (!msgs.length)
				msgs = null;
			if (errs)
				ko(errs);
			else {
				// can close to reload
				ctn.removeAttr("data-event-close");
				ok(msgs); // reload
			}
		});
	});

Es tu sur que le save des liens sont ok ?
En cas d’erreur, le formulaire ne s’actualise pas.

Emmanuelle · February 10, 2026, 4:54pm

D’accord, dans Network je vois que quand je Save, le get n’est appelé que sur les objets inlinés et pas sur mon objet père (CdpProduct).

Pour le père, p.values est encore défini avec les valeurs au moment du Save donc on passe directement dans le init.

listNav(_ => {
                    if (p.values)
                        init();
                    else {
                        ui.monitor(ctn, "get");
                        if (creation)
                            obj.getForCreate(param).then(init).catch(getError);
                        else if (p.copy)
                            obj.getForCopy(rowId, param).then(init).catch(getError);
                        else
                            obj.getForUpdate(rowId, param).then(init).catch(getError);
                    }
                }

Après le Save, si je clique sur Reload, p.value est undefined et j’ai bien mon get avec mon pourcentage à jour.

Donc mon souci viendrait plutôt de l’absence du get plutôt que de l’ordre des Save ?

[EDIT] Si je regarde le retour de l’update, je vois qu’on est avant l’exécution du postSave des objets inlinés car le pourcentage n’a pas encore été recalculé.

Après clic sur Reload, c’est fait.

Pour moi c’est un comportement normal car même hors objet inliné, si j’avais un recalcul dans le postSave de mon objet, je ne l’aurais pas à l’écran avant un reload, non ?

Dans les logs, l’ordre des hook

Save du parent

com.simplicite.objects.CDP.CdpProduct|preSave||Event: EFE preSave CdpProduct

Save objets inlinés

com.simplicite.commons.CDP.CdpProductBlock|preSave||Event: EFE preSave objet inliné CdpPdtDescription
com.simplicite.commons.CDP.CdpProductBlock|postUpdate||Event: EFE postUpdate objet inliné CdpPdtDescription

→ J’imagine que c’est là que j’ai la Response à mon update, puis
Recalcul pourcentage parent

com.simplicite.objects.CDP.CdpProduct|calculateCompletion||Event: EFE calculateCompletion 
com.simplicite.commons.CDP.CdpProductBlock|updateProductCompletion||Event: EFE save product 
com.simplicite.objects.CDP.CdpProduct|preSave||Event: EFE preSave CdpProduct

Francois · February 13, 2026, 11:06am

On a revu le traitement du save des liens inlinés pour :

les faire dans l’ordre des liens définis : des await successifs à la place du gros allSettled de promesses
et forcer ensuite un getForUpdate des données de l’objet parent avant que le formulaire ne s’affiche.

J’ai essayé avec des hooks postCreate et postUpdate sur le fils en relation 1,1 qui mettent à jour l’objet parent et ça fonctionne.

Ce sera livré en 6.2.23

system · February 13, 2026, 1:41pm

This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.