[UserScript] WaniKani Fast Abridged Wrong/Multiple Answer

Damn, looks like script is loading faster than other files it depends on.
Guess this is a good excuse to rewrite with the open framework, since it needs fixing anyways :stuck_out_tongue:

1 Like

If you do end up using the framework, [Burn Manager] is a good reference example. All the menu-related stuff is at the top of the script. I’ve started putting my scripts under an “Open” or “Settings” sub-menu, depending on what the link actually does. But I’m open to coordinating based on something different if people have other ideas.

1 Like

Actually fighting with settings at the moment. I have two scripts in progress of migration, both using Open Framework, but only the first gets its settings installed into the menu. If I turn that one off, the other does load. I’ll check out the Burn Manager to see if I can’t figure out where I’m going wrong.

I can have two scripts settings under the same sub-menu no?

Yeah, I have several installed under Open. Do they each have a different value for ‘name’? I may have code in there that prevents duplicating a name since the name is (or was originally going to be) used to create an id attribute.

There we go, thank you.

The sample at wanikani-open-framework/sample_client.js at master · rfindley/wanikani-open-framework · GitHub has script_id instead of name. Was this a renaming, or are they functionally different?

“settings_dialog = new wkof.Settings({” also utilizes script_id in the example.

I’ll update the example and check if the docs are right. I moved away from ‘script_id’ in the Menu module because it implies that it’s per-script, which doesn’t work if a script has more than one menu link. But for sake of not breaking the interface, ‘script_id’ gets copied into ‘name’.

I’m not sure if Settings supports ‘name’ yet, but it probably should. That’s the first module I wrote, and is where script_id originated since I didn’t (at the time) think about a script having more than one settings dialog. But things evolve :slight_smile:

That was it, thanks! The one place I forgot to look.

For some reason there seems to be a bug where I can’t add synonyms while doing reviews. There also is apparently some buggy stuff happening with synonyms even outside of reviews. It seems to be originating with this script, as turning it off fixes this problem.

dagnabit, I think I borked something real bad. Hang tight fellas.

Edit 1: Went to test the synonyms , and whole entire review was borked (see above statement). Reviews auto-went on after getting right, but didn’t mark as right. That seems to be straighted out. Now, back to the synonyms issue. Big failure on my part completely borking it, sorry anyone affected.

Edit 2: Uncaught Error: cannot call methods on autocomplete prior to initialization; attempted to call method 'off' umm… :flushed:

Edit 3: @rfindley So on review pages, simply calling ‘wkof.include(‘Settings’);’ causes the error in Edit 2 when attempting to add a synynom. Any ideas?

Hmmm… That sounds like a jquery or jqueryUI error (just guessing). I don’t call ‘off’ in my code, though.

Are you certain it’s just the wkof.include(), and not creation of a settings dialog? Is there anything useful in the call stack in the console?

if(window.location.href == "https://www.wanikani.com" || window.location.href == "https://www.wanikani.com/dashboard"){
        wkof.include('Apiv2, Menu, Settings');
    } else {
        wkof.include('Settings');//shorted to just this
        //A bunch of commented out stuff

clicking the ‘add synonym’

Uncaught Error: cannot call methods on autocomplete prior to initialization; attempted to call method 'off'
    at Function.error (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:1)
    at HTMLInputElement.<anonymous> (<anonymous>:6:5615)
    at Function.each (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:1)
    at pe.fn.init.each (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:1)
    at pe.fn.init.t.fn.(anonymous function) [as autocomplete] (<anonymous>:6:5357)
    at new pe.fn.init (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:2)
    at pe (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:1)
    at HTMLLIElement.<anonymous> (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:6)
    at HTMLLIElement.dispatch (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:2)
    at HTMLLIElement.g.handle (application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:2)

which brings me to application-a9d56fe7838575d6e64bf494c077af35b542a299fc31c1aebc9f33104b08df8b.js:formatted:767

        expando: "jQuery" + (fe + Math.random()).replace(/\D/g, ""),
        isReady: !0,
        error: function(e) {
            throw new Error(e)

Looking deeper, traces back, partially at least, to “this.UserSynonyms.addOption = function(e, t, n) {” But, that makes sense

this.UserSynonyms.addOption = function(e, t, n) {
        var r, i;
        return r = $(".user-synonyms-add-btn"),
        i = UserSynonyms.wrapper(),
        r.on("click", function() {
            var a, o, s, u, c;
            return $(this).hide(),
            s = $("<li></li>", {
                "class": "user-synonyms-add-form"
            u = $("<form></form>").appendTo(s),
            c = $("<input></input>", { <-- this line for some reason
                type: "text",
                autocapitalize: "none",
                autocomplete: "off",
                autocorrect: "off",
                spellcheck: "false"

And you’re saying if you comment out the include(), you get no error?
Hmm. Can you send me your current code?

I suppose it’s possible I’m accidentally overwriting some global variable that’s being used by something else.

is pretty much current, just trying a bunch of things around line 50. Commenting out the entire ‘else’ section, error goes away. But just throwing in the include() and error comes.

Okay, I’m able to replicate this. I’ll look into this tonight.


I found the problem.
@viet, you might be interested in this, if you’re not already aware.


It seems jQuery UI is incompatible with one piece of Wanikani code.
In Wanikani’s UserSynonyms.addOption(), it does this:

$("<input></input>", {
    type: "text",
    autocapitalize: "none",
    autocomplete: "off",
    autocorrect: "off",
    spellcheck: "false"

The intent is to add each parameter in the object as an attribute on the <input> tag.

The problem is that jQuery checks each parameter to see if it matches a function name in $.fn.
In this case, jQuery UI has an Autocomplete widget that places a constructor at $.fn.autocomplete().
So, instead of adding an autocomplete="off" attribute to the <input> tag, it tries to call $.fn.autocomplete("off").

You can simulate the exact same error by doing this directly (after loading jQuery UI dynamically):


I’m going to push a workaround into the framework tonight.


I’m going to dynamically remove $.fn.autocomplete after jquery_ui.js loads:

delete $.fn.autocomplete;

We’ll lose the ability to use the Autocomplete widget, but I wasn’t using it anyway, so no issue.

This makes the “add synonym” feature work like normal.


I’ll set up some tests today and see if we can avoid the function/attribute collision.


Hi! I’m not sure what I’m doing wrong but I can’t get the colors to change. I’m not one with the coding so could you tell me what to change in the code to change the colors? Thanks.

In the showBar function I believe. Not at home, so harder to check. You’d have to make a switch statement based off mode. It was a setting before, but it went away when converted to Open Framework. It’ll be making a return, but took a leave of absence to get the OF version up and running.

bonkaholic’s issue turned out to be this:

    if(window.location.href == "https://www.wanikani.com" || window.location.href == "https://www.wanikani.com/dashboard"){

The location was actually https://www.wanikani.com/ (i.e. with a slash on the end), so it wasn’t installing the menu link.
You can use pathname instead of href, since it automatically adds a "/" if one isn’t present:

    if(window.location.pathname == "/" || window.location.pathname == "/dashboard"){

I scooted the attributes out of the short-hand element constructor and added them with a .attr({…}). The code’s live so we shouldn’t have the attribute/function name conflict anymore. (JQuery UI) Autofill away!