Options ticked on by default cannot be un-ticked in the web GUI#725
Merged
Conversation
An unchecked HTML checkbox posts nothing, so htsserver never overwrites the
value it already holds. Every box in the wizard is one-way: once the stored
value is "1", whether htsserver seeded it at startup, a loaded profile set it,
or the user ticked it earlier in the session, un-ticking and submitting leaves
the option on and draws the box ticked again. Only four boxes, all in
option1.html, carried the companion hidden field that guards against this.
Add it to every remaining bare checkbox, and switch cookies and parsejava to
${ztest:...} so a cleared box emits --cookies=0 / --parse-java=0; ${test:...}
renders nothing at all when the value is empty, which is not "off" for an
option the engine turns on by default.
index, urlhack and keep-alive are deliberately left alone: their long options
are declared "single" in htsalias.c and optalias_check drops the =value, so
--index=0 resolves to -I and turns the option back on. That parser bug is
pre-existing and needs its own fix.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Xavier Roche <roche@httrack.com>
The runtime leg posted each name once, so a first-wins body parser would have passed while the fix did nothing in a real browser: post the duplicated name in both orders and assert the last value wins. Replace the four hand-written option cases with a table covering all 28 non-skipped boxes, asserting the command-line token and the Windows-profile key each state emits, plus a completeness check so a new box cannot slip through unexercised. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
…kbox-clear Signed-off-by: Xavier Roche <roche@httrack.com> # Conflicts: # tests/Makefile.am
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
…kbox-clear Signed-off-by: Xavier Roche <roche@httrack.com> # Conflicts: # tests/Makefile.am
xroche
added a commit
that referenced
this pull request
Jul 26, 2026
…overage The rewrite spools to a .sfnew temp and renames it over the page, which bypasses filecreate() and with it the HTS_ACCESS_FILE chmod the engine puts on every other mirrored file. Under a restrictive umask the pages came out 0600 while their assets stayed 0644, so a mirror served by a webserver or shared with a group lost read access on exactly the pages. chmod the spool before the rename. Two guards had no coverage: deleting the scheme/data: check in sf_resolve left both the self-test and the crawl test passing, because the fixtures resolved to paths that were absent either way, and the per-page inline budget was never exercised. The fixtures now plant a file where each guard's removal would land the walk, and a self-importing stylesheet measures the budget against a large-budget control. Charging that budget after the nested rewrite instead of before let an @import chain spend what its ancestors had already claimed and drove it negative; charge it up front and refund on failure. The attribute table missed the lazy-loading attributes hts_detect[] already downloads, so a modern page inlined almost nothing: add data-src, data-srcset, lowsrc, object@data and embed@src, and record why the rest stay links. The new web GUI checkbox had no hidden companion input, so it could be ticked but never cleared, which is what #725 fixed for every other box. Master's test 90 catches it once the branch merges. Adds a libFuzzer harness over the rewriter, since it re-serializes hostile HTML, and renames the crawl test to 91 now that master holds 87 and 90. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
xroche
added a commit
that referenced
this pull request
Jul 26, 2026
Adds a changes-race self-test (the FTP shape: notifier threads against the report path), fixtures for a transfer the crawl never completes, for a leftover file at a name the crawl mirrors fresh, and for a cache-off mirror, plus a pass with purging on. Registers the web GUI's --changes box with the clearing companion master's #725 now requires, and documents the degraded mode. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An unchecked HTML checkbox posts nothing, so htsserver never overwrites the value it already holds. Every box in the wizard is one-way: once the stored value is "1", whether htsserver seeded it at startup, a loaded profile set it, or the user ticked it earlier in the session, un-ticking and submitting leaves the option on and draws the box ticked again. Only four boxes, all in option1.html, carried the companion hidden field that guards against this.
The fix is wider than the eight options that start ticked. A posted value and a loaded profile land in the same persistent table, so any of the 30 checkboxes goes sticky once something sets it, and every bare box now gets a companion. That is enough for the twenty-odd options whose "off" state is just the absence of a flag. The ones the engine turns on by default also need an explicit disabling flag, and
${test:...}renders nothing when the value is empty, so cookies and parsejava move to${ztest:...}and a cleared box emits--cookies=0or--parse-java=0, both verified against a local server to behave like-b0and-j12.index,urlhackandkeep-aliveare deliberately left alone. Their long options are declared"single"in htsalias.c and optalias_check drops the=value, so--index=0resolves to-Iand still builds the index; emitting it from a cleared box would turn the option back on rather than off. That is a pre-existing parser bug and needs its own fix.cacheandcache2are being reworked separately, andtestallis still open: it has a companion already, but--extended-parsingmaps toopt->parseall, which defaults on, so clearing it changes nothing.GUI behaviour changes for users: options that silently could not be turned off now can be.