Dépannage

Avant toute chose, affichez dans votre page ce que voit l’application. Ce petit panneau de diagnostic fonctionne sur les deux plateformes, sans outil de développement :

const m = window.mairies;
document.querySelector('#diagnostic').textContent = JSON.stringify(
  {
    origin: location.origin,
    inIframe: window.top !== window,
    mairies: m ? { version: m.version, platform: m.platform, commands: m.commands } : null,
  },
  null,
  2,
);

window.mairies n’existe pas

Vérifiez, dans cet ordre :

1. La page est ouverte depuis l’application iPhone ou Android, par la carte lien. Dans un navigateur, y compris dans la version web de l’application de la commune, window.mairies n’existe jamais.
2. L’adresse du lien commence par https://.
3. La section « WebApp avancée » est activée, avec au moins une case cochée, et la modification a été publiée. Une section sans case cochée est désactivée à l’enregistrement. Après la publication, fermez l’écran du lien et, si besoin, relancez l’application pour qu’elle recharge sa configuration.
4. L’origine de la page est exactement celle du lien : même hôte, même port. Comparez location.origin avec l’adresse configurée. Une redirection vers www., vers un sous-domaine ou vers un service d’authentification externe suffit à faire disparaître le pont.
5. La page n’est pas dans une iframe (inIframe vaut false).
6. L’application est à jour. Une version ancienne de l’application peut ne pas connaître la WebApp avancée.
7. Sur Android, la WebView du système est à jour. Une version trop ancienne d’« Android System WebView » ne permet pas d’installer le pont. Mettez-la à jour depuis Google Play.

Si window.mairies existe mais que commands ne contient pas la fonction attendue, la case correspondante n’est pas cochée, ou l’application installée ne connaît pas encore cette fonction.

Erreur NOT_ALLOWED

NOT_ALLOWED signifie que l’application a refusé l’appel après vérification. Causes possibles :

• Case non cochée : la fonction n’apparaît pas dans mairies.commands. Par exemple, mairies.torch.on() alors que seule « Caméra » est cochée.
• Origine différente : l’appel ne vient pas de l’origine exacte du lien.
• Iframe : l’appel vient d’une frame autre que la page principale.
• auth.open vers une autre origine : l’adresse passée n’est pas en https, ou pas sur la même origine que la page (sous-domaine, autre port, identifiants dans l’URL).

Pour la caméra, l’équivalent de NOT_ALLOWED est l’erreur standard NotAllowedError de getUserMedia. Voir Caméra.

Pour les autres codes, voir Codes d’erreur.

Inspecter la page sur iOS

Les applications publiées sur l’App Store n’autorisent pas l’inspecteur web de Safari sur l’écran d’un lien. Pour mettre au point votre page :

• Testez d’abord dans Safari, sur Mac ou sur iPhone : ce qui ne dépend pas de window.mairies (mise en page, scripts, appels réseau) s’y comporte de façon très proche, WebKit étant le moteur des deux. Les autorisations (caméra notamment) restent propres à l’application.
• Dans l’application, utilisez le panneau de diagnostic ci-dessus, et affichez dans la page les codes d’erreur reçus (error.code).
• Journalisez côté serveur les étapes de votre parcours (connexion, échange du code) : c’est souvent là que se trouve la cause.

Inspecter la page sur Android

Les applications publiées sur Google Play n’autorisent pas le débogage de la WebView avec chrome://inspect. Les mêmes méthodes s’appliquent :

• Testez d’abord dans Chrome pour Android, où chrome://inspect fonctionne normalement.
• Dans l’application, utilisez le panneau de diagnostic et affichez les codes d’erreur reçus.
• Vérifiez la version d’« Android System WebView » dans les réglages du téléphone (Applications) si le pont est absent.

Si le problème persiste, transmettez à la commune la plateforme, la version du système, l’adresse de la page, le contenu du panneau de diagnostic et le code d’erreur obtenu.