[Userscript]: Double-Check (Version 2.x)

The update fixes the ‘enter’ issue, but the audio autoplay is now broken sometimes. The fix posted by Sinyaven works as expected though.

2 Likes

Yeah. Earlier today it seemed that autoplay was only working for the chosen default voice (while using Random Voice Actor) – but after doing a review batch just now it looks like both voices work, though not consistently.

Didn’t experience this autoplay issue when trying Sinyaven’s fix, but I only had a small batch remaining to test with.

2 Likes

Audio is completely broken :frowning: Fix from Sinyaven works though

Does your observation mean that advancing to a new question after completing a question blocks on a network request? I know @rfindley had made some observations that seemed to indicate they were preloading data from the new item from the reviewQueue.

I only saw that processCompleted() is async and contains

await updateQueue(currentItem, $.jStorage.get("activeQueue"), $.jStorage.get("reviewQueue"));

and drew the wrong conclusions. The next day I read @rfindley’s post about the preloading and noticed my assumption was wrong and that I should have looked into updateQueue(). The await only happens if the subjects for the activeQueue are for some reason not in memo yet, which should ideally never be the case.


EDIT: And the problem with @rfindley’s modification of my workaround is that my workaround with the MutationObserver only recognizes the execution of the WK callback

function submitCallback(override) {
    button.prop("disabled", false);
    ...
}

if button was disabled before submitCallback() is called. The second submit seems to never deactivate the button, so button.prop("disabled", false); has no effect and everything in .then() (in Double-Check)

// This is the second submit actually forwarded to Wanikani.
// It will move on to the next question.
click_submit.apply(this, arguments)
.await_submit
.then(() => {
    window.audioAutoplay = old_audioAutoplay;
    window.wkRefreshAudio();
});

is executed much later than intended.

I have tried to change the MutationObserver to also recognize the completion of the second submit by adding

mo.observe(document.querySelector('#answer-form input'), {attributeFilter: ['disabled']});

(because the second submit should reactivate the input field), but I got invalid form state errors and did not look any further into it.

@Sinyaven,
Sorry, I didn’t test with audio. I modified your implementation slightly because I thought I saw a potential async race condition, though I can’t remember the details at the moment… plus some reorganization so I would readily understand what was going on down the road without having to think about it. But I hadn’t yet looked at what Wanikani was doing in the new code… and I still haven’t, other than the item data loading scheme.

Anyway, unfortunately, I don’t have time this week to look into it other than to ask (and possibly implement) this: If I add a check to my click_submit() to only call the MutationObserver if the button is disabled immediately after calling old_submit_handler(), do you think that would fix the audio based on your current understanding of the WK code? Or maybe delay the check for 1ms or something, in case the disabling of the submit does not occur synchronously (I haven’t checked… :sweat_smile: )

Yes, that should work. In the first submit, WK disables the button immediately, and in the second submit, WK does not disable the button at all (furthermore, the second submit seems to be entirely synchronous). So there is no need to delay the check. I have also tested it with this:

	function click_submit() {
		var p = promise();
		var submitButton = document.querySelector('#answer-form button');
		var result = old_submit_handler.apply(this, arguments);

		if (!WaniKani.wanikani_compatibility_mode && submitButton.disabled) {
			// Set up callback for when 'submit' button is re-enabled after being clicked.
			var mo = new MutationObserver((mutation) => {
				if (mutation.pop().target.disabled) return;
				mo.disconnect();
				mo = undefined;
				p.resolve();
			});
			mo.observe(submitButton, {attributeFilter: ['disabled']});
		} else {
			p.resolve();
		}

		return {status: result, await_submit: p};
	}

and I did not notice any problems – neither with nor without lightning mode enabled.

2 Likes

Fantastic, thanks! I will make the change later this evening.

2 Likes

:point_right: [v2.2.39] - Fixed audio playback. Fixed statistics when changing answers.

4 Likes

How can I use a legacy version? Something in your new update broke my reviews, so now they don’t properly record.

I answer a card and it doesn’t record it on screen after I hit enter to move on to the next item. The same card will repeatedly reappear until I quit the review session. It is impossible to use the wrap up button in conjunction with the script problem. Luckily on the session score screen they do display correctly- right and wrong numbers.

All versions are available on greasyfork.org. Click on the History tab.

Do you have Script Compatibility Mode turned on or off? This version is intended for having it Off.

1 Like

I didn’t realize you had to click the version number and that clicking the bubbles does nothing

I have script compatibility mode on. I recall it fixing some problem I was having before.

Downgrading does not fix the issue somehow. I definitely didn’t have this problem last time I used a computer for WK :thinking:

For now, I can only suggest trying the latest version with Script Compatibility turned off, or a version from at least a week or two ago with script compatibity On.

1 Like

FWIW, I just finished a ~200 review pile with the latest version (2.2.39) enabled, compatibiliy mode off, and about 7 other scripts running. Didn’t seem to experience any problems…so your issue may be coming from something else.

I went through each script and tested turning them off one at a time. The only time I could get rid of the problem was when turning double check off.

It looks like things work fine with the third most recent script, thank you!

1 Like

Sorry, I think this was caused by my “Later Crabigator” userscript. It seems that WK at some point changed the way they handle hotkeys, and the newer version just clicks all buttons located in the input field if you hit Enter to proceed to the next question ($("#answer-form button").trigger("click")). This also triggered the “Later Crabigator” button, which pushed the current item to the end of the review queue. This bug should be fixed now. Both “Later Crabigator” and “Double-Check” should work correctly with both compatibility mode on/off and be compatible with each other now.


More details

The most recent versions of Double-Check made the bug more apparent, because there is now a short pause between the first and the second submit. The click handler of “Later Crabigator” executed between these submits, during the pause.

The fix took me longer than it should have – mostly because jQuery adds really strange behavior to event handling that I didn’t know of. $("#answer-form button").trigger("click") first performs bubbling for jQuery event handlers, and only afterwards (and if not cancelled), the standard event handling with capturing and bubbling is performed :man_facepalming:. And I was confused why my event handlers – even the capturing ones – were never called.

3 Likes

That’s interesting! I do have your script installed, but the problem went away when I disabled double check. I’ll try again now with the most recent versions of each. Thank you!

Edit: everything’s super smooth again! Thank you all for your help and patience!!

2 Likes

EDIT: silly me, wkof = Wanikani Open Framework; that’s the missing piece; please ignore me :see_no_evil:


Unfortunately, script is still not working for me, even with 2.2.39, with script compatibility mode on or off.

Main issue is that I don’t get the scripts menu; using Firefox (94.0.2), Violentmonkey.

Worth mentioning I get this error on the console:

ReferenceError: wkof is not defined
VMin0287lo5l0 moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/ Wanikani Double-Check.user.js#2:33
VMin0287lo5l0 moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/ Wanikani Double-Check.user.js#2:858
VMin0287lo5l0 moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/ Wanikani Double-Check.user.js#2:859
a moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
v moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
set moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/ Wanikani Double-Check.user.js#2:1
c moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
ScriptData moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
onHandle moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1
c moz-extension://5a27e9b0-7799-1e42-a58f-a03cb0cf7ec3/sandbox/injected-web.js:1