mirror of
https://codeberg.org/PostERG/xamxam.git
synced 2026-06-25 08:09:18 +02:00
6d93199fa2
Investigation verdict: - HTMX does NOT swap the FilePond container on the edit page; the htmx:targetError in the crash log is unrelated noise - The pre-destroy abort in destroyFilePondsIn has a wrong status check (filters for nonexistent status 4, misses status 7 LOADING) but is moot because no HTMX swap targets the FilePond container - The load-file-error -> DID_THROW_ITEM_INVALID path is vulnerable (passes t.status directly, unlike every other error handler which wraps it), but for local files the LOAD_FILE plugins always wrap rejections properly - Likely actual trigger: Firefox XHR abort edge case in server.load for the existing cover file, racing with addition of a new local file that replaces it in the single-file queue
1.5 KiB
1.5 KiB
TODO
HTMX v2 Migration
Reference: docs/autosave-system.md → "HTMX v2 Migration Plan" section.
contenus-edit.php(pages): Addhx-*attrs, addovertype:changedispatch in OverTypeonChangecontenus-edit.php(form_help): Addhx-*attrs, addovertype:changedispatch in OverTypeonChangeapropos-groups-form.php(contacts): Addhx-*attrs onlycontenus-edit.php(sidebar_links): Addhx-*attrs only- Add
handleAutosaveResponse()shared handler +htmx:beforeRequestloading state - Delete
autosave.js - Fix backend
$isAjaxdetection: also recognizeHX-Requestheader (page.php, apropos.php, form-help.php) - Form-help inline editors: add OverType toolbar + HTMX auto-save + remove save buttons
- Markdown cheatsheet modal: reusable dialog on all OverType editors
FilePond crash on TFE upload forms
- Analyze root cause →
docs/filepond-crash-analysis.md - Partial fixes (Content-Type headers, onerror cleanup, load object) — insufficient, crash still reproduces
- HTMX/destroy race hypothesis investigation →
docs/filepond-race-investigation.md(verdict: REFUTED; likely cause: Firefox XHR abort edge in server.load racing with file replacement) - Replace
server.loadwith custom fetch-based function to bypass FilePond'screateResponsepath entirely (see investigation doc, recommended next step) - Fix
destroyFilePondsIn()status check:f.status === 7(LOADING) not caught; needs to also cover LOADING and PROCESSING_QUEUED (status 9)