Hello, I followed your instructions and installed some of the most popular scripts, Open Framework is set as number 1, all scripts are activated but… It doesn’t work.
By that, I mean that when restarting my browser and going on WK, nothing has changed.
What did I miss ? :s
EDIT : I’m using Mozilla firefox
EDIT2 : Some of them work, but some don’t. It seems like the ones affecting the dashboard are not working.
Try opening the Javascript Console (press F12 and click on the Console tab) to see what errors you are getting.
Firefox is notorious for corrupting its indexeddb, which is where the Open Framework stores your Wanikani info, so that would be my first guess. You can clear indexeddb by opening the Storage tab (press F12 and click on Storage tab while on the WK dashboard), opening Indexed DB, https://www.wanikani.com, and right-clicking on wkof.file_cache, and selecting “Delete”. Then refresh and try again.
Also, certain privacy settings won’t allow indexeddb to be used, so you may just need to disable privacy on Wanikani if it’s enabled.
2 Likes
Indeed, I got the following errors in the console :
Content Security Policy: Les paramètres de la page ont empêché le chargement d’une ressource à eval (« script-src »).
(roughly in english : the page’s parameters blocked the loading of an “eval” ressource)
and
NotFoundError: The operation failed because the requested database object could not be found. For example, an object store did not exist but was being opened. Wanikani Open Framework.user.js:364
get_dir moz-extension://5e2bb0b9-d83d-4d67-a077-b3ca21c8fcfb/userscripts/Wanikani Open Framework.user.js?id=2a806f99-2896-439f-ad3c-049944d22678:364
also
deleting the cache file didn’t work, and I couldn’t find how to allow a privacy exception for wk in firefox menus…
The “content security policy” message sounds like an ad blocker extension (or similar) may be interfering.
Can you try temporarily turning off any such plugins? (for Wanikani only)
The other error is definitely an IndexedDB error… probably also related to security.
It’s unfortunate that some security models totally disable IndexedDB. That’s the only form of browser-side storage that is big enough to store all of the Wanikani item and progress data.
1 Like
Interestingly enough, it doesn’t work on my laptop with no ad-blocker, but everything works on my desk PC that has ad-block. Good thing I mainly use my desk PC for WK ! No bells and whistles when i’m at uni but I can live with that.
Maybe your university is injecting changes in the web traffic?
ps: en Francais, une page trés technique sur le fonctionnement de CSP (Content Security Policy) Entête HTTP : Politique de sécurité du contenu (CSP) - Trucsweb.com
I’ve tried logging in on my laptop at home and the result is the same
So it seems that most people are running this script using Tampermonkey. As mentioned earlier in the thread, it does not currently work with Greasemonkey. I am trying to get this script to work in qutebrowser which has its own userscript implementation which actually currently differs a bit in behavior from both Tampermonkey and Greasemonkey. The details can be seen on this GitHub issue. The maintainer of qutebrowser has indicated a desire to more closely match the behavior of Greasemonkey, so I will be assuming for the rest of this post that the necessary changes get made and focus on the remaining reasons Open Framework doesn’t work in Greasemonkey. I’m relatively new to the inner workings of userscripts, so hopefully the information I’ve gathered is accurate.
- Greasemonkey 4.x removed the UI for ordering scripts which used to exist in Greasemonkey 3.x. The scripts are loaded and executed in alphabetical order, so this can be worked around fairly easy. The user just needs to edit the name of each of their scripts to include a numeric prefix indicating the order they need to be loaded.
- Greasemonkey does not allow access to the global
windowobject.* Instead it allows access to the properties ofwindowthrough a proxy object sharing the same name. Basically this means that Greasemonkey scripts can read values from the global scope, but cannot edit them. Instead, edits or newly created properties are associated with the proxy object. These are not visible in the global scope but can be seen from other scripts because Greasemonkey passes the samewindowproxy to each script. The problem is that Open Framework executes the external modules it loads by injecting them into the DOM as script tags. These scripts get executed in the global scope and cannot accesswindow.wkof. The reason things work alright in Tampermonkey is that it does not currently use awindowproxy and instead allows all scripts to directly mutate the global scope. This is actually unintended and is slated to be changed at some point in the future. See the TODO comments here. If this change gets made, Open Framework won’t work in Tampermonkey either. One possible fix would be to fetch the text of the external modules and run them usingevalfrom within the scope of the script itself. Loading the external modules with the@requiredirective might work too. As far as I can tell, neither of these approaches would require any changes to be made to other scripts relying on the Open Framework.
In summary, I think there is a good opportunity to increase compatability and futureproof the Open Framework script here.
* It is technically possible to access the real window using unsafeWindow but this is considered bad practice.
1 Like
In TamperMonkey, using “@grant none” intentionally disables sandboxing and runs the script in the page context, which allows all of the scripts based on Open Framework to interact with the framework and each other.
Script injection was a conscious choice because sandboxing works differently in different combinations of browser and script manager (or at least it used to). So, if anything, maybe the fix would be to convert the Core portion of Open Framework to an injected script, and then create a ‘loader’ script to do the injection.
1 Like
Thanks for the clarification; I was not aware that @grant controlled the sandbox for Tampermonkey. Good to know.
If I understand your proposed fix correctly, the part of the code which generates the wkof interface would be run from a script tag the same way the other external modules are currently being run? Then the main Open Framework script would just be responsible for fetching and injecting the other scripts and the sandbox (or lack thereof) would be irrelevant. Seems reasonable to me.
Yes, exactly.
Heyo @rfindley - thanks so much for making this! This is a really cool framework ^.^ - I was wondering if you had any tips or suggestions for other devs in regards to making a framework for other sites? Anything you learned along the way you found particularly helpful or any posts or articles or books or whatnot you’d recommend? Would love to try and make something like this to learn more about it myself!
I did see you have the code open sourced on github so will be taking a look at that, too (thanks for doing that).
1 Like
Mostly, the ideas for the framework came from writing scripts and ending up doing some things repeatedly. Also, seeing other scripters writing code to do things that I had already done. So, it’s essentially about seeing a need and filling it. It also helps to always be thinking ahead about how other people might want to use an API.
The main thing that was new to me when developing the Open Framework was Javascript Promises. I had used them before, but not in any complex way. So, I spent a fair amount of time finding flexible ways to use them in solving problems.
Some of the deeper code in the framework is more of a mess than it really should be, but you learn as you go, and it takes a while to develop maturity in your programming style as you learn new languages, features, and APIs. So, it’s good to practice and learn from other people.
(Unfortunately, even after extensive study and use, Promises feel like somewhat of a cumbersome workaround for one of Javascript’s weaknesses. They do solve a lot of problems, but it’s easy to make things more complex than they really need to be. Maybe it’s just my way of thinking due to experience in other languages, but in those other languages it’s not even a problem that needs to be solved, so… take that for whatever it’s worth 
)
2 Likes
Thanks so much for the detailed reply - appreciate it
I’m trying to use Double-Check, and installed both that and Open Framework (Open Framework is #1), but somehow my Wanikani interace isn’t changing 
Any ideas on what it could be? Some more details…
- I have Chrome
- The TamperMonkey extension turns black when on Wanikani (which makes me think it should be working, but then my UI is the same)
- I’ve heard of people toggling certain Double-Check features on/off, but don’t see a way to do this in TamperMonkey. Maybe this toggling is the secret (need to toggle features on specifically)?
I’m assuming you saw the images in the Double-Check thread to know what to look for? Specifically, the Scripts menu in the upper-left corner of the Reviews screen. If you don’t see that, then open the Javascript Console (press F12 and click on the Console tab), and post any errors you see there.
Thank you! That was the missing piece, it works now Double-check is amazing!
Hello! I just wanted to flag that the Open Framework seems to be taking waaay longer to load my data over the past couple of days. It used to take a couple of seconds, but now I’m probably waiting for around a minute for it to load everything (I managed to make a cup of tea this morning while waiting to look at my heatmap 
).
I thought it was just something on my end, but @Rowena mentioned that they’ve had the same issue.
1 Like
Is this still occurring? There was an issue with the Heatmap which caused it to fetch a bunch of extra reviews every time you loaded the dashboard. I fixed it yesterday, but the fix meant you had to re-fetch all your reviews, which takes a long time.
2 Likes