ElabNET Technik Forum

Hallo Zusammen,

ich habe seid dem Update auf V4.5 ein Problem beim Zugriff/Login auf das System und Visu mit meinen Wand-Tablets iPad Air 2 mit aktuellstem IOS 15.8.2. Erst hatte ich das Problem nur bei einem Tablet, nachdem ich die Visu mit den neuen Möglichkeiten etwas erweitert habe auch mit dem zweiten Tablet.
Dabei kam erst die Meldung das der Client der Visu ein Update bracht, also die Seite neu geladen werden muss (ich betreibe die Tablets im Kiosk-Modus). Als ich das gemacht habe, wurde erst die Meldung angezeigt das der Visu Client geupdated wird und seid dem komme ich weder auf die Visu noch kann ich mich mit den Tablet einloggen.
Zugriff ist bei beiden Tablet über timberwolfxxx.local bzw. timberwolfxxx.local/visu.

Es erscheint nun bei beiden iPads immer die folgende Nachricht:



Versucht habe ich bis jetzt folgendes:
- Mehrmaliges Löschen aller Webseitendaten (Cache)
- Mehrmaliger Nestart
- Löschen und erneute Installation und Aktivierung des TWS Zertifikat
- Test im Privaten-Modus

Interessanterweise komme ich mit timberwolfxxx.local/proxy/visu auf die im Docker laufende CV, ebenfalls geht das mit ip/proxy/visu.

Hat irgend jemand eine Idee an was das liegen kann?

Grüße Ralf

Hallo Ralf

Das iPad Air2 wurde von 2014 bis 2016 hergestellt und die iPadOS springt jetzt gerade von Version 18 auf 26. Somit ist Version 15 lediglich die "aktuellste" oder besser letzte Version, die Apple für dieses Gerät noch herausgebracht hat.

Ich weiß zwar nicht welche Systemanforderungen sich im TWS in den letzten Updates geändert haben könnten, aber ich erinnere mich, dass ich mit ähnlich alten iPads ebenfalls den TWS irgendwann nicht mehr nutzen konnte. Ich bin kein Webentwickler und kann diese Umstände entsprechend nicht einschätzen, aber Elabnet wird sicher nicht absichtlich den Support für alte Browser einschränken. Es werden entweder IT-security Gründe oder Voraussetzungen für irgendein Feature sein, die diese alte iOS Version nicht unterstützt.

Hallo Parsley,

deine Argumentation verstehe ich und mir war auch klar das so etwas in den Raum geworfen wird.

Die Frage an Elabnet ist jedoch noch, wenn bis zum Update des TWS die Tablets keine Probleme mit dem Zugriff auf den TWS hatten, bis heute keine Probleme bei normalen Webseiten aufgetaucht sind (incl. Homebanking) und dann nach dem Update des TWS kein Zugriff auf die TWS-Oberfläche möglich ist (CometVisu im Docker funktioniert ja nach dem Update noch), dann würde ich mich schon interessieren was zur V4.5 im Bezug auf dem Zugriff auf das TWS-System geändert wurde?


Noch eine Anmerkung von mir, die 10 Jahre alten Tablets haben gestern noch mal Sicherheit-Updates von Apple bekommen.
Für das Problem hat sich jedoch nichts geändert.



Grüße
Ralf

Hi Ralf,

uns sind keine generellen Probleme mit älterer Apple Hardware bekannt. Es gibt drei Kunden, die ähnliches berichten, allerdings mit unterschiedlicher Hardware und auch verschiedenen Versionsständen von 12.x bis 15.x. Auf meinen iPad von 2016 mit IOS 16.7.8 funktioniert alles.

Frage: Funktioniert der Aufruf der administrativen Webseite des Timberwolf Servers?

lg

Stefan

SchlaubySchlu hat geschrieben: ↑Di Okt 21, 2025 8:19 pm Die Frage an Elabnet ist jedoch noch, wenn bis zum Update des TWS die Tablets keine Probleme mit dem Zugriff auf den TWS hatten, bis heute keine Probleme bei normalen Webseiten aufgetaucht sind (incl. Homebanking) und dann nach dem Update des TWS kein Zugriff auf die TWS-Oberfläche möglich ist (CometVisu im Docker funktioniert ja nach dem Update noch), dann würde ich mich schon interessieren was zur V4.5 im Bezug auf dem Zugriff auf das TWS-System geändert wurde?

Mir ist nichts bekannt was an dem Zugriff geändert wurde und dieses Problem auslösen würde.

Mein Verdacht ist eher dass auf eine neue Funktion zugegriffen wird, welche auf den alten Geräten nicht existiert und dann zu einem Abbruch des Programms führt. Leider kann man bei Apple die Fehler nicht direkt auf dem Gerät sehen, sondern muss das Gerät per USB mit einem Mac verbinden und weitere Schritte ausführen: https://www.lifewire.com/activate-the-d ... ari-445798

Ich habe hier ein iPhone 8 mit Version 16.7.21 darauf kann ich die VISU aufrufen.

Viele Grüße,
Matthias

Hallo Stefan, Hallo Matthias,

ich habe zwischenzeitlich schon mit meinem besten Mitarbeiter über das Thema philosophiert und ich werde das was Matthias vorgeschlagen hat, sobald ich dazu komme testen.

Wenn ich mehr herausgefunden habe melde ich mich wieder.

Ist aktuell echt dumm, meine Familie hat sich in die TWS-Visu gewöhnt und jammert schon dauernd

Grüße
Ralf

So, nun bin ich weiter und die Sache sieht wie folgt aus.

Beim Laden von timberwolf196.local werden in der Konsole die folgenden Meldungen angezeigt.



Die Meldung leitet mann an die folgende Zeile Code / Funktion



In der Funktion scheint eine für den Safari 15.xx Invalid regular Expression verwendet zu werden.

Es sieht so aus als ob die in der Funktion verwendete Funktion

function h(a) {
                    return a.replace(/\/\*[\s\S]*?\*\/|(?<=[^:])\/\/.*|^\/\/.*/g, "").trim()
                }

eine Look-behind-Assertion (?<=[^:]) verwendet die der Safari 15 nicht interpretieren kann. Er sieht (?< und denkt, es wäre eine benannte Gruppe, meldet deshalb "Invalid regular expression: invalid group specifier name"

Laut Netz, da ich kein Webentwickler bin, soll eine solche Funktion Kommentare entfernen.

Die Frage ist, braucht man das wirklich so umgesetzt?

Ich konnte das mit einem IPAD 6.Generation (IpadOS 17.7.8) testen, dort geht es.


Allen einen schönen Sonntag.

Gruß
Ralf

Hallo Ralf (@SchlaubySchlu),

Danke für deine Meldung! Die Funktion wird genutzt um Kommentare aus der Logik-Code zu entfernen, das ist korrekt. Wir haben bereits eine alternative Lösung, der auch auf ältere Geräte laufen sollte. Wir werden uns das ansehen und in den kommende Insider Preview erweitert testen.

Das betrifft aber nur der Admin UI. Das andere (die VISU Client) ist hiervon nicht betroffen. Könnten Sie /visu aufrufen und die Konsole-Meldungen auch noch auswerten? Das wäre hilfreich.

Danke im Voraus!

Hallo Michaël,

kein Problem, ich werde das selbe mit dem Visu-Aufruf machen und das Ergebnis posten.

Gruß
Ralf

So, ich habe es mit timberwolf196.local/visu versucht und war überrascht das gar nichts geladen wird. Da habe ich beim schreiben des Thread wohl etwas falsch beschrieben.
Das Debuggen zeigt auch keine Fehler, ich kann nur die serviceworker.js sehen. Diese habe ich mal ChatGPT geben und gefragt was den Safari 15.X aus den Tritt bringen kann.

Das war ist Antwort.

Kurzfassung: Deine serviceworker.js ist grundsätzlich modern und okay – aber es gibt 3 Stellen, die Safari/WebKit 15 (iPadOS 15.x) in der Praxis gern „aus dem Tritt“ bringen und bewirken können, dass Seiten nicht fertig laden oder scheinbar hängen:

1) fetch-Event: Branch ohne respondWith

In deinem Code:

self.addEventListener('fetch', function(event) {
  ...
  let cache = self.findCacheMatch(event.request);

  if (!cache) {
    console.info('no cache found');
    return fetch(event.request);   // <- Problematisch in Safari 15
  }

  event.respondWith(
    caches.open(cacheName).then( ... )
  );
});

Wenn du einen fetch-Listener hast, solltest du immer event.respondWith(...) aufrufen – auch beim einfachen Netz-Fallback.
Safari 15 hat (je nach Build) den unschönen Edge Case, dass ein fetch-Listener, der manchmal kein respondWith setzt, zu doppelten oder hängenden Netzwerkzugriffen führen kann.
Fix (sicher für alle Browser, inkl. Safari 15):

self.addEventListener('fetch', function(event) {
  const cache = self.findCacheMatch(event.request);

  if (!cache) {
    event.respondWith(fetch(event.request));  // <-- immer respondWith
    return;
  }

  const cacheName = cache.name;
  event.respondWith(
    caches.open(cacheName).then(cache => {
      return cache.match(event.request).then(response => {
        if (response) return response;
        return fetch(event.request.clone() /*, {cache: 'no-cache'}*/).then(res => {
          if (res && res.status < 400) cache.put(event.request, res.clone());
          return res;
        });
      });
    })
  );
});

2) cache-Option im fetch-Init

fetch(event.request.clone(), { cache: "no-cache" })

Safari 15 hat bei Request.cache-Modi (v. a. in Service Workern) teils inkonsistentes Verhalten. Meist wird die Option ignoriert (okay), aber es gibt Setups, bei denen das Zusammenspiel mit dem SW-Cache zu unerwarteten Cache-Treffern oder fehlenden Updates führt.
Empfehlung: Für Netz-Fetch im SW ohne Cache-Interferenz einfach ohne die cache-Option arbeiten (oder no-store testen). Am zuverlässigsten ist: Option weglassen.

3) Robustheit von findCacheMatch / URL-Parsing

self.findCacheMatch = function(request) {
  var url = new URL(request.url);   // kann bei Nicht-HTTP(S) scheitern
  ...
}

Bei nicht-HTTP(S)-Requests (z. B. data:, blob:, chrome-extension:) kann new URL(...) eine Exception werfen. Das passiert selten – aber wenn, reißt es den Fetch-Handler ab und die Seite lädt nicht fertig.
Fix (defensiv):

self.findCacheMatch = function(request) {
  try {
    const url = new URL(request.url);
    for (const key of Object.keys(CURRENT_CACHES)) {
      if (url.pathname.match(CURRENT_CACHES[key].match)) {
        return CURRENT_CACHES[key];
      }
    }
  } catch (e) {
    // Nicht-HTTP(S) oder ungültige URL -> nicht cachen
  }
  return null;
};

4) (Optional, aber wichtig für Safari) activate sauber nutzen
Du hast install + skipWaiting(), aber kein activate. Safari 15 bleibt mitunter beim alten SW hängen, bis ein Tab wirklich neu geöffnet wird.
Ergänzen:

self.addEventListener('activate', (event) => {
  event.waitUntil(self.clients.claim()); // Kontrolle sofort übernehmen
});

5) Unkritisch, aber nice to have
console.debug(...) ist ok; zur Sicherheit ggf. vorher console.debug = console.debug || console.log;.
Object.values/Set sind in Safari 15 vorhanden – passt.
Deine Regexe enthalten keine Look-behinds (die wären in Safari 15 problematisch); also hier alles gut.

TL;DR – Drop-in Patch
Ersetze in deinem SW:
Fetch-Branch ohne respondWith → immer event.respondWith(fetch(...))
Lass die cache: "no-cache"-Option weg
Mach findCacheMatch try/catch-robust
Füge einen activate-Handler mit clients.claim() hinzu

evtl hilft euch das weiter.

Gruß
Ralf