Discussion :

[Trebly]

Bonjour,

J'ai précédemment ouvert une discussion sur les fonctions javascript propres aux navigateurs qui permettent de gérer fenêtres ou onglets.
L'écho a été faible.

Je reviens sur le sujet, mais sous un autre angle, poser le problème global fonctionnel en faisant appel aux réponses et idées de chacun (même si j'ai bossé très longtemps ces sujets sans avoir pu apporter de réponse que je juge satisfaisante). Et l'on verra ensuite le problème des outils nécessaires et utiles.

Le contexte (je prends le cas Wordpress pour ceux qui connaissent l'outil, mais ma réflexion est applicable à tous les gestionnaires de contenu):

Nous avons un blog (Wordpress) qui doit supporter des documents longs (plusieurs dizaines d'équivalent pages de livre soit à partir à peu près de 400 lignes de texte, long article jusqu'à 5 000 et plus, essais, livres...), Wordpress prévoit alors de les découpe en "pages" que je préfère appeler "sections" qui ont une adresse différente (c'est le nom que j'ai choisi dans mes docs pour éviter les confusions de langage). (voir note sur la manière de découper le texte dans wordpress)

Le problème

Le problème que je pose est : Comment fait-on, pendant la lecture du texte principal, pour consulter par exemple la bibliographie (ou tout autre "section" du même type, index, table des matières générale) sans qu'un nouvel onglet soit ouvert à chaque fois que l'on veut accéder à ces "sections" ?

Bien entendu il faut conserver les avantages fondamentaux des pages et articles Wordpress (ou autre gestionnaires de contenu HTML) en matière de gestion de liens, d'introduction de multimédia etc...

Le comportement de l'application que l'on attend (à la base) :

• Quand l'on clique sur un élément bibliographique, la première fois un nouvel onglet s'ouvre, mais ensuite l'onglet bibliographie déjà ouvert va, tout en récupérant le focus, se positionner sur l'item du lien cliqué.
• On peut alors revenir au point de lecture en cours sur l'onglet principal.
• Le sommaire ou table des matières permet de se positionner en un click à un endroit quelconque du document global

On peut aller bien plus loin dans les fonctions mais le mieux est, je pense, de s'arrêter à ça dans un premier temps.

Il va de soit que notre "outil" doit résister aux fermetures intempestives, à l'arrêt accidentel, aux duplications d'onglets ou déplacement vers d'autres fenêtres, toutes fonctions autorisées par les navigateurs ou leurs plugins.

Je veux bien, in fine, ajouter la fonction plus générale : consulter plusieurs sections (chapitres d'un document) simultanément, et accéder à l'élément d'index, de la bibliographie etc. uniques en un click, ça peut être bien pratique pour étudier un document, n'est ce pas ce que l'on fait avec un document papier, non ?

Quand on a résolu les problèmes fondamentaux de manipulation de fenêtres et d'onglets, il n'y a en fait plus de limites aux développements ergonomiques.

Voilà, j'ai fini.

Merci d'avance pour vos idées et questions.

Bien cordialement

Trebly

note : On obtient le découpage en introduisant un pseudo balise "<!--nextpage-->", des plugins annexes permettent de nommer les sections et de générer un menu des "sections" - pour un essai, par exemple, ce seront des Chapitres...et à la fin les section particulières que sont index, bibliographie, table des matières générale etc..

[Watilin]

Je ne sais si j’ai bien compris ton problème ou si c’est plus compliqué que ce que je pense.

Sans connaître l’architecture du CMS utilisé, tu devrais être en mesure d’écouter les clics sur les liens de bibliographie – pour reprendre ton exemple – et de faire ouvrir la nouvelle page dans une fenêtre, à laquelle tu donnes un nom. J’ai vu dans l’historique de tes topics que tu connaissais déja le principe des fenêtres nommées.

Le problème est que tu n’as pas de moyen fiable de faire ouvrir la page à coup sûr dans un onglet plutôt qu’une fenêtre séparée, en arrière-plan plutôt qu’en avant-plan, etc. Les navigateurs ne donnent pas cette possibilité aux développeurs, car ils considèrent que le choix doit être laissé à l’utilisateur de paramétrer ces comportements à sa convenance.

Ainsi, si tu veux fixer un même comportement dans toutes les situations, il faut passer par du code avec de plus grands privilèges, et du coup tu ne développes plus une application mais une extension. Je n’ai pas l’impression que ce soit ton objectif.

Concernant les fermetures intempestives ou accidentelles, tu peux utiliser des requêtes en arrière-plan pour sauvegarder sur un serveur l’état dans lequel est l’application, à intervalles réguliers. Mais cela nécessite que tes utilisateurs soient enregistrés.

(Un emploi d’ajax que je trouve particulièrement astucieux consiste à faire une requête synchrone lors de l’évènement unload pour envoyer des informations au serveur.)

Concernant la duplication d’onglets, une fenêtre nommée résoud la moitié du problème. Pour l’autre moitié on peut imaginer faire passer des informations d’une fenêtre à l’autre en utilisant postMessage.


Autrement, tu peux avoir envie de mettre en place un suivi automatique du défilement (scroll tracker). J’en ai vu un qui permettait d’avoir toujours au bas de l’écran les notes relatives à la partie actuellement visible de la page, mais je ne le retrouve plus :/
De la même manière, tu peux afficher la table des matières dans un panneau latéral (comme dans les lecteurs PDF).
Ces deux idées te permettent de te passer des onglets. Mais je ne sais pas si tu trouveras un plugin qui remplit ce rôle de manière satisfaisante.


Voilà, ce sont seulement quelques pistes, mais j’espère que ça peut t’aider.

[Trebly]

Bonjour,

Bien on va pouvoir construire quelque chose.

Pour te répondre je vzais d'abord utiliser les citations pour les points où un accord est nécessaire pour aller plus avant :

• Je ne sais si j’ai bien compris ton problème

  Plutôt : le problème que je pose problème pour lequel dans le cas que je formule (simplifié mais qui pose le cœur du problème) auquel je n'ai pas de bonne réponse (du moins pas trop compliquée, et j'ai développé une bibliothèque plutôt importante de fonctions qui ne marche pas encore bien, voir plus loin).

• Le problème est que tu n’as pas de moyen fiable de faire ouvrir la page à coup sûr dans un onglet plutôt qu’une fenêtre séparée,

  . Si, par défaut si l'on n'indique pas de paramètre dans window.open un onglet sera ouvert et non une fenêtre (

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  window.open(url,name,'') // ouvre un onglet pour l'url
  window.open("",name,"") // renvoie un handle -ref de l'onglet name existant ou ouvre un nouvel onglet portant le nom name et blank, l'instruction précédente le peuplera

  )

• Ainsi, si tu veux fixer un même comportement dans toutes les situations, il faut passer par du code avec de plus grands privilèges, et du coup tu ne développes plus une application mais une extension. Je n’ai pas l’impression que ce soit ton objectif.

  Tout à fait exact, en particulier les bibliothèques "tabs" ne peuvent être utilisées alors qu'elle le seront avec des plugings.

• Concernant les fermetures intempestives ou accidentelles, tu peux utiliser des requêtes en arrière-plan pour sauvegarder sur un serveur l’état dans lequel est l’application, à intervalles réguliers. Mais cela nécessite que tes utilisateurs soient enregistrés.

  Oui mais pas les références aux onglets ouverts, juste la table des noms et autres data utiles (voir le problème plus loin)
  
  Donc, non, pour le stockage ça marche très bien j'utilise une combinaison de cookie et localstorage pour sauver l'environnement de l'application en cas de crash (par contre je rappelle que les références aux onglets ne peuvent être sauvées, cela n'aurait d'ailleurs aucun sens sauver un pointeur...).
  Par contre pour le courant, je passe tout en mémoire en utilisant les handles de fenêtres ouvertes (j'ai pour tous les onglets ouverts un seul pointeur vers l'objet "tabs"). Tant que la fenêtre d'origine reste ouverte elle est maitre mais quand elle est fermée elle repasse le bébé à la suivante (toute modification est donc visible depuis tous les onglets). J'envisage par la suite d'utiliser Ajax pour sauver cet environnement et pouvoir le retrouver sur toute machine utilisée. Cela touche aussi d'autres données telles l'historique de visite et des marque pages et annotations (un Diigo dédié et intégré en quelque sorte). Par contre le contrôle et la restauration d'environnement reste impossible, voir plus loin.

• Concernant la duplication d’onglets, une fenêtre nommée résous la moitié du problème. Pour l’autre moitié on peut imaginer faire passer des informations d’une fenêtre à l’autre en utilisant postMessage.

  Malheureusement non, je parle de la duplication faite soit par le navigateur soit par un plugin, ils génèrent dans ce cas un doublon, eh oui. Seule la dernière sera visible et l'autre restera masquée (le handle mémorisé accèdera à la fenêtre référencée mais window.open('',<name>,'') renverra le handle de la copie... (constaté une fois j'ai abandonné la gestion des doublons, je devrai refaire un test pour confirmer, mais aussi développer une démo tant il y a de St Thomas ici, mais qui ne sont pas assez intéressés pour vérifier par eux-mêmes). Il semble que les noms soient stockés dans une liste (comme je fais) et que la recherche s'arrête à la première rencontrée (laissant le seconde masquée). On peut d'ailleurs forcer une fenêtre à se renommer pour vérifier l'existence d'un doublon par exemple, mais ça on en sait pas bien faire...). Pour ce qui est du partage de données j'utilise en fonctionnement courant directement javascript en conservant la liste des pointeurs vers les onglets, cela fonctionne parfaitement (si l'onglet n'a pas été détruit entre temps..., et ça c'est un crash de navigateur, donc une gestion d'erreur est indispensable).

• De la même manière, tu peux afficher la table des matières dans un panneau latéral (comme dans les lecteurs PDF).

  Oui, c'est ce que je fais (il n'y a pas de plugin WordPress qui le fasse, il me faudrait un acolyte pour le produire), j'ai un ensemble assez important (entre 3 et 4000 lignes de code) qui génère en php la table des matières et une bibliothèque locale qui gère le contenu de volets latéraux (nombre illimité avec des widgets, dont la table des matières, mais aussi la liste des onglets ouverts, l'historique etc...). La première difficulté a été d'ailleurs (ce que ne fait aucun plugin gestionnaire de sommaire de Wordpress) de créer un sommaire qui comprend les liens "externes" pour les "sections" qui ne sont pas la section courante dans un document découpé (Ceci a obligé à développer une bibliothèque complète pour gérer tous les clicks sur liens).

Le problème des index et autres tables des matières est qu'il est commun, le plus souvent, à plusieurs onglets ouverts (quand on clique un lien du texte vers lui-même mais dans un autre section en demande "nouvel onglet"). Tout cela impose la gestion d'un objet "tabs" commun a tous les onglets qui contient à la fois les onglets ouverts et pour lequel les références sont correctes dont l'onglet auquel on veut donner le focus par un instruction du type

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<thetab_handle>.<element>.focus()

", mais aussi les onglets fermés ou "pourris".

En fait le problème absolument essentiel est l'impossibilité pratique de nettoyer et garder des références devenues invalides, et pourquoi ? Parce qu'il est impossible en l'état actuel du jeu d'instruction de vérifier si un onglet dont on a le nom (tables courante ou restaurée depuis le stockage, mais évidemment sans handle) existe ou non. Pour vérifier le seul outil est window.open("",<name>,"") qui a le défaut rédhibitoire d'ouvrir obligatoirement un nouvelle onglet si le nom n'existe pas et avec ça, non seulement on peut aller à l'encontre de la volonté de l'utilisateur (qui a pu fermer l'onglet en utilisant la "X", mais on plante la plupart des navigateurs sous Android par la répétition d'ouverture-fermeture d'onglets lors de contrôles effectués par l'application). En conséquence on ne peut pas vérifier, on peut juste ouvrir un onglet par une action volontaire de l'utilisateur.

Je suis persuadé que pour faire quelque chose de fiable il faudrait disposer de l'instruction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

window.open('',<name>,"check=yes") // returns NULL si le nom n'existe pas, le handle vers l'onglet si il existe

Qui retournerait "null" si elle n'existe pas (au lieu d'ouvrir un nouvel onglet) sinon le handle de la fenêtre au lieu de l'ouverture par défaut.

En ce qui concerne la sécurité je ne vois pas quel problème cela pourrait poser, à condition que l'utilisateur prenne les précautions utiles pour protéger son système de noms, le tout en sachant que l'accès aux noms ne peut être exécuté que pour un même domaine.

Pour l'instant j'ai donc du abandonner :

• le test de doublons
• le nettoyage correct des erreurs (lors de restaurations ou lors de l'affichage de la liste) et le test d'un onglet correctement référencé mais pointant vers un onglet détruit, caché... d'où une gestion d'erreurs rigoureuse nécessaire. L'objet "tabs" permet doc de lister dans un panneau latéral les onglets ouverts ou fermés volontairement (historique), outil de navigation dans le document et optionnellement dans tout le blog, et assurant de manière annexe la gestion d'historique comme le font divers plugins et navigateurs
• la restauration correcte d'une session sur le blog (après un crash). Les onglets sont, ou non, ré-ouverts par le navigateur, mais le rapprochement de la table sauvée et de l'état du navigateur est impossible. L'utilisateur a donc à sa disposition uniquement la liste des onglets théoriquement ouverts (non contrôlée) et le click ouvrira éventuellement un doublon (néanmoins le restauration après crash avec Chrome, FireFox, Opera restaure les noms).
  

Le tout, de ce que j'ai écrit, constitue une bibliothèque qui reste lourde et complexe et n'offre pas la fiabilité souhaitable ni encore pour l'utilisateur l'ergonomie que je vise.
Le volume serait probablement divisé par un facteur cinq si l'instruction "window.open avec check name" existait.

J'ai déja essayé d'expliquer l'utilité de cette évolution de l'instruction "window.open" que je propose, mais je n'ai pas eu d'écho.
Je pense soumettre le sujet au développement Mozilla prochainement. A noter que cette évolution respecte une parfaite compatibilité ascendante (comportement identique en l'absence du nouveau paramètre) et qu'il n'y a que quelques lignes de code à changer sans risque d'incidences.

J'ai évidemment conscience de bâtir une application qui possède des fonctions internes d'un navigateur (onglets ouverts, historique), mais aussi des fonctions supplémentaires et constitue une bibliothèque qui peut devenir importante en tant qu'outil de développement (en JQuery à 70%).

Malheureusement de plus l'instruction window.open se comporte dans le détail de manière différente d'un navigateur à l'autre.
Sans :

• une uniformisation du comportement de la fonction (dont l'unicité des noms dans un domaine et l'accès par le nom dans un domaine quelque soit la filiation des fenêtres)
• l'instruction que je propose qui permet de tester les noms et synchroniser une table de noms et les onglets réellement ouverts

Le problème me parait inextricable, ce qui interdit le développement de toutes les fonctionnalités que j'ai évoquées.

Cordialement

Trebly
_________________________________________________________________________________________________
Note1 : le tout c'est 5000 lignes de js (200ko compressé) et 8000 pour la génération de sommaire en php (mais c'est techniquement indépendant), ceci, pour le volume de travail, sans compter les adaptations de plugins Wordpress externes qui se sont avérés nécessaires.
_________________________________________________________________________________________________
Note2 : je pense que peu de développeurs imaginent les possibilités qu'offrent le développement que j'ai amorcé et qui est très loin du spécifique.
_________________________________________________________________________________________________
Note3 : Mozilla English window.open donne des informations. J'y ai ajouté une note à propos du comportement variable des navigateurs (non encore introduite en version française). Je modifie en ajoutant cette note3. Je viens de vérifier que avec chrome (dernière version courante) la règle selon laquelle window.open("",<name>,"") renvoyait le handle du <name> dans le domaine n'est pas appliquée correctement. Chrome fonctionne toujours avec la règle de la hiérarchie d'ouverture. Seul un "ancestor" (parent) peut accéder à une fenêtre par son nom sinon un doublon (même url) est ouvert. Hors comme il est impossible de tester les doublons de noms de multiples fenêtres pourront porter le même nom et seront inaccessibles. De plus si des données sont saisies il a a un risque de confusion et d'incohérences majeur.

[Watilin]

Je crois que je commence à comprendre. À cause des différences d’implémentation, le recours à open pour reconstruire des références est à la fois non fiable et instable. Il faut donc mettre en œuvre une solution moins hacky, qui n’appelle open que quand on est sûr du résultat, autrement dit en se limitant à la fonctionnalité dont le support est garanti partout.

Quand j’ai parlé de postMessage j’avais presque oublié l’existence de localStorage. Effectivement, si tu n’as pas de problèmes de domaine/origine, utiliser localStorage est plus simple. À ce propos, je ne crois pas qu’il soit judicieux de mélanger les cookies localStorage, ce dernier pouvant être vu comme une amélioration des premiers.

J’imagine une solution basée justement sur localStorage. Il servirait de canal de communication entre les différentes fenêtres. Chaque fenêtre se verrait attribuer un id ad hoc, je veux dire par là pas un handle, mais quelque chose qui peut se sérialiser (Il faudra réfléchir à la façon d’attribuer cet id. Dans le scope JavaScript de la page elle-même, pas pérenne. En dur dans le code HTML, cela demanderait l’implication du serveur. À creuser.)

Une table des ids serait maintenue dans le localStorage, et à chaque id serait associée une file de messages. Chaque page consulterait sa propre file à intervalles réguliers (système de polling). Il y aurait également une file spéciale * pour les messages adressés à toutes les pages (broadcast).

Une application de ces messages serait de vérifier si une page donnée existe toujours. La page mère émettrait le message « est-ce que tu existes toujours » à une page fille, et attendrait la réponse un temps suffisamment long (par exemple, si l’intervalle de polling est de 100 ms, une attente de 300 ms me paraît raisonnable) avant de faire les opérations nécessaires. Bien sûr il faudra s’occuper de l’intégrité de la table.

Est-ce que cette proposition te paraît applicable ?

[Trebly]

Bonjour,

Bon, comme j'ai beaucoup travaillé le sujet depuis près de deux ans, j'ai déjà beaucoup de réponses et des commentaires à faire sur chacune de tes réflexions et remarques.

Je crois que je commence à comprendre. À cause des différences d’implémentation, le recours à open pour reconstruire des références est à la fois non fiable et instable. Il faut donc mettre en œuvre une solution moins hacky, qui n’appelle open que quand on est sûr du résultat, autrement dit en se limitant à la fonctionnalité dont le support est garanti partout.

Tout à fait d'accord, ceci étant, pousser à ce que window.open assure un service standard de base ne me parait pas inutile même si c'est à long terme. En effet à propos de ta proposition finale, malgré son intérêt sur le plan formel, je suis presque certain, que l'on butera à nouveau sur la même question : récupérer le handle sur des fenêtres nommées dans un domaine et je crains qu'il n'y ait pas de solution en dehors de ma proposition sur window.open (voir détail plus loin).

Quand j’ai parlé de postMessage j’avais presque oublié l’existence de localStorage. Effectivement, si tu n’as pas de problèmes de domaine/origine, utiliser localStorage est plus simple. À ce propos, je ne crois pas qu’il soit judicieux de mélanger les cookies localStorage, ce dernier pouvant être vu comme une amélioration des premiers.

C'est bien ce que j'avais pensé. Ceci étant le(s) cookies (j'en ai 3) ne conservent pas de données, mais uniquement les méta-données (y compris sur les local storages) : droits, marqueurs dates, dates limites, validité etc... Je n'ai pas vu provisoirement l'utilité d'utiliser un localstorage dédié remplaçant les cookies. Le droit ouvert aux cookies pour le site par l'utilisateur étant par ailleurs le sésame (voir note 2).

J’imagine une solution basée justement sur localStorage. Il servirait de canal de communication entre les différentes fenêtres. Chaque fenêtre se verrait attribuer un id ad hoc, je veux dire par là pas un handle, mais quelque chose qui peut se sérialiser (Il faudra réfléchir à la façon d’attribuer cet id. Dans le scope JavaScript de la page elle-même, pas pérenne. En dur dans le code HTML, cela demanderait l’implication du serveur. À creuser.)

Bien d'accord, c'est ce que j'ai fait. Chaque fenêtre qui prend le focus, nouvel enfant ou existante, prend le contrôle du localstorage pendant que celui qui l'a perdu en a fait la mise à jour, puis il le modifie avec un timer à partir d'un objet local (voir note 1) pendant que les opérations exécutées affectent l'objet conservé en mémoire. Une fenêtre nouvelle du domaine non enfant prend le contrôle en l'état.
Pour le id (window.name) des "data-*" sont récupérées dans un div cachée dans le html en tête de document. Ces data alimentent le gestionnaire de noms qui sont les identifiants d'onglets. Le gestionnaire de noms identifiants (une lib dans un objet) s'occupe de tout.
Néanmoins, s'il est possible de gérer correctement ces id dans l'objet il n'est pas possible d'assurer totalement la synchronisation et interdire totalement la production de doublons de noms (note 3), le gestionnaire nettoye.

Une table des ids serait maintenue dans le localStorage, et à chaque id serait associée une file de messages. Chaque page consulterait sa propre file à intervalles réguliers (système de polling). Il y aurait également une file spéciale * pour les messages adressés à toutes les pages (broadcast).

Là je ne fais pas comme ça. Comme dit plus haut, comme une seule à le focus à la fois, tout le monde partage la liste de ce qui a été ouvert et référencé (et fait les purges utiles automatiquement). Cela marche bien, on sait quels onglets sont ouvert (ou ont été) car c'est le récupération des handles qui rend impossible le fonctionnement.
En effet comme il est impossible de récupérer les handles de manière fiable, on ne peut jamais être sur que, depuis la liste (manager des onglets ouverts et de l'historique) ou lors de l'appel via d'un lien contenu où que ce soit :
on n'ouvrira pas un nouvel onglet alors qu'il l'est déjà (avec le risque d'incohérence si des données sont en train d'être saisies : annotations, marques pages, commentaires...) et ceci bien que ces données soient aussi sauvées en localstorage (note 4).

Une application de ces messages serait de vérifier si une page donnée existe toujours. La page mère émettrait le message « est-ce que tu existes toujours » à une page fille, et attendrait la réponse un temps suffisamment long (par exemple, si l’intervalle de polling est de 100 ms, une attente de 300 ms me paraît raisonnable) avant de faire les opérations nécessaires. Bien sûr il faudra s’occuper de l’intégrité de la table.

Proposition fort intéressante. On peut créer ainsi une fonction remplaçante de window.open(check). Quant à l'opération de contrôle d'intégrité elle existe déjà dans mon développement.
Malheureusement cela ne règle toujours pas la question d'origine : comment dans un même domaine à partir de n'importe quel onglet toujours pouvoir accéder, passer le focus, à un onglet que l'on sait être ouvert sans risquer de l'ouvrir en double.

Depuis près d'un an et demi, j'ai pu, avec chrome, à partir d'un onglet ouvert pour un chapitre (section 1) de document long, accéder de manière répétitive à un onglet "bibliographie" (section 11) en me positionnant dans chaque "fragment" utile, en ayant ouvert la bibliographie à partir de ce chapitre.
Mais comme on va le comprendre c'est un cas très spécifique non généralisable.
En effet si l'on ouvre le chapitre suivant du texte, ce chapitre étant un onglet frère (section 3) de la bibliographie (section 11), ne pourra récupérer le handle de ce frère bibliographie (section 11) et l'activation d'un lien vers la bibliographie ouvrira immanquablement une nouvelle instance de la bibliographie (avec chrome c'est sur, vérification en cours sur d'autres navigateurs... mais cela n'apporte que de l'eau à mon moulin).

Bien, tout en rédigeant je crois que je tiens quelque chose : Après chaque création d'onglet enfant, il peut récupérer normalement le handle du parent ou de l'opener (et je ne m'en suis pas servi jusqu'à présent). On deviendrai donc capables (voir ma note 1) de reconstituer la famille de handles.
J'attaque le sujet... (voir note 5). Echec.

Le problème est, me semble-t-il insoluble en l'état de la technique. J'ai perdu beaucoup de temps (note 6) pour un résultat bien maigre (mais prêt pour le futur...).

Le problème d'ergonomie que je ne résous pas est que, très rapidement, quand je teste la consultation du site que je tente d'ouvrir, après un demi heure de (re)lecture d'un texte de 100 pages en dix chapitres, je me trouve, alors que je vérifie les liens vers une bibliographie, avec un grand nombre d'onglets ouverts très souvent en double rendant le travail inextricable (note 7). Seul j'y arrive mais les tests effectués avec des relecteurs (j'ai plus de mille pages à publier) sont un échec, d'où mon développement. Et je ne vois vraiment pas quel outil utiliser compte tenu de l'investissement déjà réalisé.

Nota (rappel) : ça serait tout de même sacrément simple d'avoir l'instruction "window.open('',<name>,'check=yes')" qui retournerait le handle de la fenêtre (ou onglet) <name> connue dans le domaine ou null si elle n'existe pas...
et que, au moins, focus() puisse être exécuté pour n'importe quel handle acquis sur un des élément inclus dans la famille de fenêtres.
(voir note 8).

Je n'arrive toujours pas à comprendre pourquoi si peu de gens s'intéressent à ce sujet. Tu est le seul qui ait compris, je crois bien, l'importance de la question.
C'est je pense le clef de la consultation de documents longs autrement qu'en pdf.

Je dois, peut-être, me poser des questions avec dix ans d'avance...

Cordialement

Trebly
_____________________________________________________
note 1 :
Dans la pratique je gère un objet principal "tabs" qui comprend deux sous objets qui sont des array d'objets

1. l'array des références de tab (ouvertes et historique)
2. l'array des handles correspondant à des onglets ouverts

Quand un onglet est ouvert avec un handle connu une double relation 1-1 est établie (index réciproques)

La première est l'équivalent d'un historique dans lequel les onglets ouverts sont référencés comme tels donnant accès au handle
Le deuxième est une table des onglets ouverts du domaine pointant vers la première

Toute anomalie est soit résolue soit purgée, seul l'élément historique est alors conservé.

Malheureusement cela ne fonctionne que pour des liens parent-enfant gérés via window.open et avec chrome.
______________________________________________________
note 2 : le problème du blocage des cookies : s'il existe des plugins pour détecter et valider l'autorisation de l'utilisation des cookies avec WP, rien n'est dit (je n'ai pas trouvé) sur les droits à utiliser le localstorage. Pour l'instant j'ai considéré que l'autorisation donnée par l'utilisateur d'utiliser les cookies était valable pour le local storage, je verrai dans les test (il y a tellement de variantes).

______________________________________________________
note 3 : car il ne faut pas oublier que les ouvertures, fermetures etc... sont asynchrones et que beaucoup de choses peuvent se produire pendant qu'un onglet se recharge ou qu'un nouvel onglet s'initialise. Les mises à jour lors des changements de focus arrivent à stabiliser partiellement l'état. Le seul "ticket" valide serait mon "window.open('',<...>,'check=yes')".
______________________________________________________
note 4 : Leur récupération en cas d'ouverture en double (double de l'url, pas nécessairement de nom) est assurée (autres localstorages) mais cela devient une vraie usine à gaz (en faire une API stable ou des plugins WordPress me parait impossible). Local ou ajax et base de données cela aboutit à afficher n fois le même contenu, sans pouvoir maintenir l'unicité autrement que manuellement (grâce à la liste gérée et affichée qui ne peut même pas dire si un onglet est ouvert ni y accèder) c'est tout simplement absurde.

_____________________________________________________
note 5 : Test de l'accès aux handles de fenêtres par leur nom (window.open("",<name>,"")) dans un domaine
Réponse (partielle mais suffisante):
Chrome ne connait que la filiation via window.open et l'opener est l'onglet (la fenêtre) qui a exécuté window.open.
Il n'est possible d'accéder à une fenêtre par son nom (via wx=window.open('',<name>,'') que si l'onglet qui exécute l'instruction est celui qui a ouvert l'onglet, donc qui connait en principe déjà le handle.
wx.focus() passera le focus à cet enfant généré via window.open, mais l'inverse est impossible.
Appairées (chacun a le handle sur l'autre) les deux onglets connaissent réciproquement et peuvent manipuler leurs données.
Par contre tout enfant généré par un lien standard restera inconnu et inatteignable (opener non défini et parent est "self")...

Firefox reconnait, lui, toutes les fenêtres du domaine (et l'on accède ou modifie les données), un point important correspondant à la doc mozilla sur window.open, par contre les commandes <element>.focus() sont ignorées ce qui rend impossible l'exécution des fonctions souhaitées.

________________________________________________________
note 6 : j'ai passé entre 1000 et 2000 heures sur le développement, tout n'est pas perdu loin de là mais pour le résultat obtenu il y a dix fois trop de temps passé. Mais j'ai commis l'erreur de ne pas faire suffisamment de test élémentaires de toutes les configurations et de prendre les docs comme du bon pain sans tout vérifier. Ensuite j'ai développé sans me rendre compte que je développais une bibliothèque correspondant au seul cas qui marche et sur lequel j'effectuais en fait les test. Puis in fine, la bibliothèque fonctionnant assez bien quand j'ai étendu les cas d'ouverture d'onglets par d'autre moyens que window.open (très vite complexes) j'ai cherché des anomalies dans mon code... puis les test sur les différents navigateurs ont fait apparaitre des différences...

________________________________________________________
note 7 : très vite une trentaine d'onglets ouverts dans un travail de correction et de mise à jour de liens concerant deux ou trois chapitres sur dix (onglets auxquels s'ajoutent les pages d'édition des chapitres en cours de modifs)? Cela devient vite inextricable, alors que quatre suffiraient (complétés de quatre pages de modifs sur une fenêtre séparée).
Le problème est que, un même onglet peut être requis à partir, à la fois de plusieurs moyens (lien simple, duplication ou ouverture manuelle, window.open lancé par un opener - seul cas qui fonctionne -, etc...) et à partir de plusieurs documents (chapitres qui consultent la même bibliographie), et presqu'à chaque fois la même url est réouverte dans un nouvel onglet et si l'on veut gérer manuellement l'on risque de fermer celle qui marche (qui est capable de récupérer le focus) sans pouvoir du tout rétablir la hiérarchie des onglets ouverts.

________________________________________________________
note 8 : dans ce cas l'établissement d'un tableau des onglets ouverts (relation 1-1 entre noms uniques et handles) et partagé entre les onglets du même domaine devient presque immédiat et tous les problèmes tordus tombent d'un seul coup.