[fullerhkz]

Fixes #13: the Add Torrent dialog stays open after a successful add.

What changed

js/dialogs.js, in enhanceAddTorrent(): after the existing syncAdd() call, listen for the end of an upload this dialog started (an uncancelled submit, then the load of the matching hidden iframe uploadfrm / uploadfrmurl). Core's load handler (addTorrentFinished in content.js) is registered first, so by the time ours runs the source field already reflects the server answer:

• field empty (at least one success): dispatch change / input on it so the file chips and the Add button re-sync, then theDialogManager.hide("tadd");
• field still filled (failed or duplicate): nothing happens, so the dialog stays open for a correction, as before.

init.js carries the regenerated CQB_REV (bash bin/stamp.sh --write), as in earlier fix commits. CHANGELOG.md and changelogs/ are untouched, since the release automation writes them.

Verification

• bash bin/ci-local.sh: ALL GREEN (conventional commit, version consistency, node --check, string catalog, stamp check, selftests).
• Headless Chrome against an isolated copy of a real ruTorrent instance. POST php/addtorrent.php was intercepted and answered with the same 302 to addtorrent.php?result[]=<status>&name[]=... the real server sends, so the real ruTorrent code rendered the toasts and nothing was added.

Scenario	Server result	Before	After
File	Success	dialog stays open	closes
URL	Success	stays open	closes
Several files	Success	stays open	closes
File	Failed	stays open	stays open (field kept)
File	Duplicate	stays open	stays open (field kept)
Reopen after success	Success	old chip, Add enabled	no chip, Add disabled

Also confirmed on the live instance.

Not tested: the stock ruTorrent theme and the Create / RSS / other add dialogs (they do not use this code path).

Disclosure

The investigation and the patch were prepared with the help of an AI assistant (Claude, via OpenClaw) and verified in a real browser by the submitter. Please review it like any other change.

[JMSDOnline]

Hey @fullerhkz, thanks for putting this together, it works on ruTorrent 5.3.19.

I tested it on 5.3.18 too though, and a few things need changing:

• On 5.3.18 and older, ruTorrent clears the file field after every add, even failed ones, so the dialog also closes when an add fails. Most installs are still on 5.3.18 since 5.3.19 only just came out.
• If you pick a file, hit Cancel and open the dialog again, the old file still shows and Add is still enabled.
• If a slow URL add finishes after you closed and reopened the dialog, it closes the dialog on you.

The version below fixes all three. It reads the result ruTorrent sends back (result[]=Success), which works on every version, and it also blocks a second click on Add while an add is still running. I tested it on both versions.

Replace your block after syncAdd(); with this, and change line 324 to var dz = wireDropzone(zone, chips, fileInput, { multiple: true, onChange: function () { syncAdd(); } });

		/* Core empties #torrent_file and #url with .val(""), which fires no
		 * event: on every open (beforeShow) and after a confirmed add
		 * (addTorrentFinished). Re-read both so the chips and Add match. */
		var opened = 0;
		function resync() {
			dz.renderChips();
			syncAdd();
		}
		if (window.theDialogManager && theDialogManager.addHandler) {
			theDialogManager.addHandler("tadd", "afterShow", function () { opened++; resync(); });
		}

		/* Close the dialog once an add is confirmed. Core answers an upload by
		 * redirecting the hidden frame to addtorrent.php?result[]=<status>&...,
		 * one final status per item (Success, Duplicate, Failed...), so the frame
		 * URL says whether anything was added. The source field cannot: ruTorrent
		 * 5.3.18 and earlier empty it after every answer, refusals included. Only
		 * a load that follows a real submit counts (the frame also loads once,
		 * blank, when core inserts it). Add stays disabled while the upload is in
		 * flight, and an answer that lands after the dialog was closed or reopened
		 * leaves the dialog alone. */
		function addedAny(frame) {
			try {
				return new URLSearchParams(frame.contentWindow.location.search).getAll("result[]").indexOf("Success") >= 0;
			} catch (e) {
				return false;
			}
		}
		function closeAfterAdd(form, frameName) {
			var frame = document.querySelector('iframe[name="' + frameName + '"]');
			if (!form || !frame) return;
			var pending = false, sentIn = -1;
			form.addEventListener("submit", function (e) {
				if (e.defaultPrevented) return;
				pending = true;
				sentIn = opened;
				add.disabled = true;
			});
			frame.addEventListener("load", function () {
				if (!pending) return;
				pending = false;
				resync();
				var dm = window.theDialogManager;
				if (addedAny(frame) && sentIn === opened && dm && dm.visible && dm.visible.indexOf("tadd") >= 0) {
					dm.hide("tadd");
				}
			});
		}
		closeAfterAdd(formFile, "uploadfrm");
		closeAfterAdd(formUrl, "uploadfrmurl");

Also please point the PR at development instead of latest (anything merged to latest is released right away), then run bash bin/stamp.sh --write and bash bin/ci-local.sh.

Thanks again!

[fullerhkz]

Thanks a lot for testing on 5.3.18 and for the rewrite, @JMSDOnline. You're right: I only tested on 5.3.19, where the field stays filled after a refusal, so I used "field is empty" as the success signal. Reading result[]=Success is the better signal.

Updated the PR:

• Applied your block after syncAdd(); as is, with var dz = wireDropzone(...) on the dropzone line.
• Rebased onto development, retargeted the PR to it, regenerated CQB_REV with bash bin/stamp.sh --write. bash bin/ci-local.sh is ALL GREEN.
• Credited you with a Co-authored-by trailer, since the logic is yours now.

I re-ran the scenarios in headless Chrome against a copy of a real ruTorrent 5.3.19 instance, with POST php/addtorrent.php intercepted and answered with the real server's 302 -> addtorrent.php?result[]=<status>, so nothing was added:

Scenario	Result
File, URL, several files: Success	dialog closes, chip gone, Add disabled
File: Failed / Duplicate	dialog stays open, file kept
Reopen after a success	no chip, Add disabled
Pick a file, Cancel, reopen	no chip, Add disabled
Slow URL add (2 s), close and reopen meanwhile	dialog stays open when the answer lands
Double click on Add	one request only
5.3.18 behaviour, simulated (core clears the field after every answer): Failed	dialog stays open
5.3.18 behaviour, simulated: Success	dialog closes

I could not run a real 5.3.18, so that last pair is simulated by making addTorrentFinished clear the field unconditionally. Your own test on 5.3.18 is the authoritative one.

I'm also running this build on my own instance now.

[JMSDOnline]

Checked it, the code matches what I tested and the checks pass on my end. Merging into development, it'll ship with the next theme release. Thanks again!

[fullerhkz]

Awesome, glad everything checks out! Thanks again for the help and for getting this merged. My pleasure contributing to the project!