This makes more sense. The implication is this may not be a bug. Perhaps they suppress Backspace for reasons similar to those of @rfindley in Self Study Quiz. How to react to a keypress without an event to respond to?
Perhaps Viet can narrow down the scope of their keypresses suppression to avoid harming wkof. An email may still be a good idea IMHO.
The alternative is to do without Backspace and move the cursor before the offending characters and use Delete.
OK, I found the place in WK’s native code where they block backspace on the reviews page. It blocks backspace (keycode 8) unless their input has focus, probably to prevent unintended navigation away from the page. However, using backspace to go back has been removed from Chrome/Safari for a while and is scheduled for removal from Firefox within the next 1-2 months. So they could probably just remove catching backspace entirely in a month or two.
Below is some workaround code. I also have pasted their code that causes the issue for reference.
Workaround Code:
$('#id_of_my_input').on('keydown', function(e) {
if (e.keyCode === 8)
e.stopPropagation();
});
Their code:
var e, t;
return t = $("#user-response"),
e = $("#answer-form button"),
$(document).on("keydown.reviewScreen", function(n) {
var i;
if (i = n.metaKey || n.altKey || n.shiftKey || n.ctrlKey,
$("#reviews").is(":visible") && !($('[class^="note-"] textarea').is(":focus") || $(".user-synonyms input").is(":focus") || $("#front-chat-container textarea").is(":focus")))
switch (n.keyCode) {
case 8:
if (!t.is(":focus"))
return !1;
break;
[...]
Not sure if this is the correct thread/topic but since yesterday I noticed that all WK scripts stopped working. Upon closer inspection I notices in JS console following errors:
10:20:05.645
GEThttps://js.stripe.com/v3/m-outer-ff599b5032b79ea1f89ba5416bea26e6.html#url=https%3A%2F%2Fwww.wanikani.com%2Fdashboard&title=WaniKani%20%2F%20Dashboard&referrer=https%3A%2F%2Fwww.wanikani.com%2Freview&muid=356f9f8e-73d8-4d31-a6f6-76b66c0ee0d2a41924&sid=f59f6b9e-f3ef-420e-971f-d301a5e03443d4c967&version=6&preview=false
[HTTP/2 200 OK 73ms]
10:20:05.646
XHRGEThttps://greasyfork.org/scripts/38578-wanikani-open-framework-menu-module/code/Wanikani%20Open%20Framework%20-%20Menu%20module.js?version=849947
CORS Missing Allow Origin
10:20:05.647
XHRGEThttps://greasyfork.org/scripts/38576-wanikani-open-framework-settings-module/code/Wanikani%20Open%20Framework%20-%20Settings%20module.js?version=850176
CORS Missing Allow Origin
10:20:05.649
XHRGEThttps://greasyfork.org/scripts/38581-wanikani-open-framework-apiv2-module/code/Wanikani%20Open%20Framework%20-%20Apiv2%20module.js?version=747866
CORS Missing Allow Origin
10:20:05.898 Content Security Policy: Las opciones para esta página han bloqueado la carga de un recurso en inline (script-src). injected.js:1:5003
10:20:06.074
XHRGEThttps://chat.frontapp.com/c532927ea41813134eb816f1c64dfd46/settings?v=1622881205754
[HTTP/2 200 OK 41ms]
10:20:06.075
GEThttps://chat-assets.frontapp.com/v1/c8112b185055a57d21e8b59c8456083a.ogg
[HTTP/2 206 Partial Content 67ms]
10:20:06.077
GEThttps://js.stripe.com/v3/fingerprinted/js/m-outer-b8cbec1166aab48d1e5a12e8ab272ac1.js
[HTTP/2 200 OK 77ms]
10:20:06.275 Solicitud desde otro origen bloqueada: la política de mismo origen impide leer el recurso remoto en https://greasyfork.org/scripts/38578-wanikani-open-framework-menu-module/code/Wanikani%20Open%20Framework%20-%20Menu%20module.js?version=849947 (razón: falta la cabecera CORS 'Access-Control-Allow-Origin').
10:20:06.275 Solicitud desde otro origen bloqueada: la política de mismo origen impide leer el recurso remoto en https://greasyfork.org/scripts/38581-wanikani-open-framework-apiv2-module/code/Wanikani%20Open%20Framework%20-%20Apiv2%20module.js?version=747866 (razón: falta la cabecera CORS 'Access-Control-Allow-Origin').
10:20:06.275 Solicitud desde otro origen bloqueada: la política de mismo origen impide leer el recurso remoto en https://greasyfork.org/scripts/38576-wanikani-open-framework-settings-module/code/Wanikani%20Open%20Framework%20-%20Settings%20module.js?version=850176 (razón: falta la cabecera CORS 'Access-Control-Allow-Origin').
10:20:06.317
GEThttps://m.stripe.network/inner.html#url=https%3A%2F%2Fwww.wanikani.com%2Fdashboard&title=WaniKani%20%2F%20Dashboard&muid=356f9f8e-73d8-4d31-a6f6-76b66c0ee0d2a41924&sid=f59f6b9e-f3ef-420e-971f-d301a5e03443d4c967&version=6&preview=false
[HTTP/2 200 OK 56ms]
10:20:06.325
XHROPTIONShttps://us-west-1-chat-server.frontapp.com/initialize
[HTTP/2 200 OK 206ms]
10:20:06.349
Uncaught (in promise)
Object { error: "Failure loading module", loaded: [], failed: (1) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.353
Uncaught (in promise)
Object { error: "Failure loading module", loaded: (1) […], failed: (3) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.353
Uncaught (in promise)
Object { error: "Failure loading module", loaded: [], failed: (2) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.354
Uncaught (in promise)
Object { error: "Failure loading module", loaded: (1) […], failed: (1) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.354
Uncaught (in promise)
Object { error: "Failure loading module", loaded: (1) […], failed: (2) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.355
Uncaught (in promise)
Object { error: "Failure loading module", loaded: (1) […], failed: (3) […] }
Wanikani Open Framework.user.js:149:25
10:20:06.356
Uncaught (in promise)
Object { error: "Failure loading module", loaded: (1) […], failed: (2) […] }
Wanikani Open Framework.user.js:149:25
It looks like there is some problem with missing CORS headers (?!) but why would it be a problem?
EDIT: aaaannd it’s working again without me doing anything. weird.
I had to refresh Firefox and reinstall all scripts.
While I’ve gotten things to work again during reviews, I’m still having issues with getting my scripts to execute on the Dashboard
I have the latest version of Firefox and these are my console messages
I had to delete and reinstall the Framework to get the scripts to work during reviews…but why didn’t that also fix the dashboard scripts?? 
EDIT
After restarting my computer I managed to get also the Dashboard scripts to start working again…it was still pretty strange, as simply refreshing the browser or shutting it down and starting Firefox again didn’t have any impact. Weird, but I’m glad to see my scripts up and working again. ^>^
It seems that Greasy Fork (where the scripts are hosted) is partially down. I’m having trouble accessing several userscript sites, so I’m pretty sure that’s the issue behind scripts not working properly today.
Well, that certainly explains all the 502 Bad Gateway messages! 
OK, but that’s quite weird. I already have the scripts installed locally so they just should execute without issue. I could understand if connectivity issues with WK API would prevent some scripts from funcioning correctly, but being affected by greasyfork outage is kinda weird.
EDIT - it looks like checking for the version update on OpenFramework fails, and when it fails the OF is not loaded (which in turns prevents the rest of the scripts from loading). However - it seems like a violentmonkey issue?
The Open Framework script that is installed through Violentmonkey does not contain the actual functionality – instead it fetches the actual code of each module from Greasy Fork on demand. That code is then cached in IndexedDB so that it doesn’t have to be redownloaded from Greasy Fork every time. But if for some reason the required code is not in the cache, and Greasy Fork is down, this WKOF module won’t be available:
And in consequence all scripts relying on that module will also fail to work.
Oh! that explains everything. Though… kinda weird approach. I assume that this is done to somewhat circumvent some limitations? It would be way better to have it completely offline as the cache can “vanish” (as it seemed in this case of mine)
Hi guys! Installing my first add on but i’m getting stuck at this part. I’ve sorted the ‘#’ column but the Open Framework icon isn’t appearing!
Never mind, apparently I can’t read. Figured it out 
Is it possible to have the following line added to the metadata at the start of the script:
// @weight 999
Some userscript software uses this to decide the load order. The number 999 being loaded first, and the number 1 being loaded last.
So something like this:
Hi! Can’t seem to get some scripts to work (e.g. Double-Check).
Also don’t see the scripts menu icon, which makes me think that the issue is with Open Framework.
I keep hearing that there’s a bug in various versions of Chrome and/or TamperMonkey. To be honest, I haven’t been able to replicate the problem here, though I use Brave browser, which is Chrome with tracker-blocking built in.
Eventually, when I have a break in my schedule, I’ll try installing Chrome to see if I can replicate the problem. Until then, maybe try Brave or Firefox if you can.
Thanks for the reply. All works well with Firefox + TamperMonkey combo 
Good luck finding the cause of the problem!
I’m pretty sure my Wanikani Open Framework is failing to load on Firefox with ViolentMonkey. Only userscripts I have activated are Double Check and Rendaku Information. Is this a known issue?
The problem was reported before in a different thread:
It seems that Violentmonkey’s synchronous page mode uses a different injection method that still works, so you could enable this as a workaround. Or you could switch to Tampermonkey.
I’ve switched to Tampermonkey for now, thanks!
I think there must have been a recent update to Firefox which is blocking the script via violentmonkey that is being worked around by tampermonkey. I found that if you enable synchronous load it will work on violentmonkey, although I ended up switching to tampermonkey as even with synchronous load on it would sometimes fail to load the script randomly which was annoying.
I am wondering if there is a way to automatically check for new versions or do I have to do it manually? I’m only using Open Framework and Double check on an iPad with Userscripts since it doesn’t look like tampermonkey is supported for mobile Safari. Maybe I’m just ignorant.
I guess if it’s manual I’ll wait until it breaks - just trying to avoid a disaster in a review session.
