Halb Fehler, Halb Wunsch

  • Hallo,

    Der Fehler:
    mir ist aufgefallen, dass es aktuell nicht möglich ist, einen Ajax Request abzubrechen. Es gibt zwar AjaxRequest.abortPrevious(), der _previousXhr wird aber mMn falsch gesetzt.
    Im sendRequest wird der previousXhr gesetzt, bevor der neue xhr erstellt wird. Ein abortPrevious() bricht also nicht wirklich den letzten, sondern den vorletzten xhr ab.

    Code
    if (this._xhr instanceof XMLHttpRequest) {
          this._previousXhr = this._xhr;
        }
    
        this._xhr = new XMLHttpRequest();

    Somit gibt es keine Möglichkeit den aktuell laufenden Request abzubrechen.

    Der Wunsch:
    Ich habe ein eigenes Uploadformular und bräuchte die Möglichkeit Uploads abzubrechen. Da ich von Core/Upload ableite, gibt es diese Möglichkeit derzeit nicht, da der Request nur lokal erstellt wird. Wäre es möglich die Requests pro uploadId zu halten, sodass man darauf zugreifen kann?

    • New
    • Official Post

    Hallo,

    der Sinn und Zweck von abortPrevious() ist es, eine noch laufende Abfrage abzubrechen, die an denselben Endpoint gerichtet ist. Ein Anwendungsbeispiel dafür sind Vorschläge bei einem Eingabefeld, bei denen sich die Eingabe ändert, bevor die Antwort eingetroffen ist.

    Eine Anpassung von Core/Upload ist nicht geplant, denn wir arbeiten aktuell an einer komplett neuen Upload-Pipeline, die (zukünftig) als Ersatz für sämtliche Uploads dienen wird. Ein Abbruch von Uploads ist dabei aber auch nicht geplant, welchen konkreten Anwendungsfall hast du hierfür?

  • Den Zweck von abortPrevious verstehe ich, nur tut es das nicht. Hier der Code dazu (abgeürzt Ajax/Request und für Testzwecke angepasst):

    Ausgabe:

    Code
    nothing to abort
    send request 1 
    
    nothing to abort
    set previousXhr to request 1
    send request 2 
    
    abort previousXhr 1
    set previousXhr to request 2
    send request 3 

    Beim Absenden von Request 2 wird Request 1 nicht agebrochen, sondern erst beim senden von Request 3, während Request 2 weiterläuft.
    Ich kann mir irgendwie nicht vorstellen, dass das das gewünschte Verhalten ist?

    Auf einer meiner Websites können Nutzer Videos hochladen und möchte Ihnen gern die Möglichkeit geben, solche Uploads abzubrechen, wenn sie doch zu lange dauern sollten. Ohne abbrechen würde evtl. unerwünschte Uploads stattfinden, die dann auf dem Server verarbeitet werden müssen. Der Request wird zwar abgebrochen, wenn der Nutzer wegnavigiert, aber zum Beispiel nicht, wenn er den Dialog, in dem das Formular ist, schließt.

  • Das behebt den Fehler. Leider kann man jetzt weiterhin nur einen Request abbrechen, wenn man einen neuen hinterher schickt. Aber wundert mich nicht mehr, dass ihr nur noch Sachen machen, die ihr für eure eigenen Features benötigt

    Edited 2 times, last by Warly (April 19, 2024 at 11:57 AM).

  • Für mich hat sich das nach einer Aufforderung gelesen, vor allem in Verbindung mit dem Vorwurf im letzten Satz. So ganz eindeutig war das nicht formuliert. Aber da ich nicht ausschließen möchte, dass es anders gemeint war, habe ich meinen Beitrag nun quasi entfernt. ;)

  • Das stimmt, das war missverständlich von mir. Tut mir leid. Mir ging es darum, dass der Fix den Use-Case von WoltLab behebt. Wenn man aber einfach nur einen laufenden Request abbrechen möchte, geht das auch weiterhin nicht. (unabhängig davon ob WoltLab meinen Wunsch Upload Requests abbrechen zu können, gut findet oder nicht). Der Aufruf abortPrevious hat einfach keine Funktion, da der previousXhr erst richtig gesetzt wird, wenn ein neuer Request abgesetzt wird.

    Ist schon krass, dass WoltLab lieber ihre API bricht, als eine Funktion zu unterstützen die sie selber nicht brauchen <X=O

    Edited once, last by Warly (April 20, 2024 at 12:07 PM).

    • New
    • Official Post

    Das behebt den Fehler. Leider kann man jetzt weiterhin nur einen Request abbrechen, wenn man einen neuen hinterher schickt.

    Nein, dafür gibt es die separate Methode AjaxRequest.abortPrevious(), dafür braucht es keinen erneuten Aufruf von sendRequest().

    WCF/ts/WoltLabSuite/Core/Ajax/Request.ts at 7e7d94ee7c37a060b1b9a02acff3ec9a8e9e1d4a · WoltLab/WCF
    WoltLab Suite Core (previously WoltLab Community Framework) - WoltLab/WCF
    github.com
  • Und durch euren "Fix" wird this._previousXhr 3 Zeilen vor dem Aufruf von this.abortPrevious(); in sendRequest() gesetzt. Das bedeutet, dass abortPrevious() nur beim Aufruf von sendRequest() funktioniert, da sonst this._previousXhr nicht richtig gesetzt ist. abortPrevious() ist damit ein ausgelagertes Implementation Detail von sendRequest() und nach dem "Fix" noch mehr ohne Funktion als vorher schon.

    • New
    • Official Post

    Danke für die Klarstellung, ich verstehe jetzt, worauf du hinaus wolltest. Das Problem ist somit, dass es zwei verschiedene Bugs gab, ich aber nur den ersten Fehler (_previousXhr wird zu spät gesetzt) erkannt habe.

    Tim Düsterhus hatte zwischenzeitlich angemerkt, dass _previousXhr vermutlich komplett entfernt werden kann und die bestehende Logik auf _xhr geändert werden sollte, da es faktisch keinen Mehrwert bietet.

    • New
    • Official Post

    Bei der Arbeit an dem Korrektur für den 2. Bug ist mir aufgefallen, dass sich in _finalize() ein dritter Fehler versteckte. Wenn bei mehreren in-flight requests eine spätere Request fertig ist, bevor die vorhergehenden Requests abgearbeitet wurden, konnte _xhr vorzeitig gelöscht werden.

    Reliably cancel an in-flight request · WoltLab/WCF@5f09a02
    The `_previousXhr` property was not reliably set previously and the current in-flight was not visible unless a new request was dispatched. The updated control…
    github.com

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!