This script completely stopped working for me on firefox (still works on chrome) after the latest update. In fact, I have to disable it, otherwise all my other WK scripts stop working as well. What could be causing the problem?
I have same problem. I have two scripts installed on my Firefox - leech trainer and this - and both seem to do absolutely nothing. There are no error messages or other indicators, TamperMonkey is active, and shows both scripts as active, yet nothing happens.
I had another report on Github for this, but for me it’s still working (FF 62.0.3 on OSX, Tampermonkey 4.8.5847, also on Windows) …
Can you try to set the Tampermonkey >> Settings >> Logging Level to Debug and see what happens in the console (Ctrl-Shift-K) when you load the page?
If you just want to get using again you can also downgrade using this link, you may have to turn off auto-update for Keisei in the settings (click on the script name in the Tampermonkey menu, then Settings).
I have the same versions of FF and Tampermonkey running on Windows. I set it on debug and disabled everything but Keisei. Only thing that appears on the console when I load a relevant page is: ‘Empty string passed to getElementById().’
edit: downgrading works
Hmm quite mysterious, it should look like this:
I’m not literally using
getElementById, looks like a change is throwing off Tampermonkey totally. I will check the changes and see if there are some reports on this, FF often introduces some security changes that tend to break Tampermonkey.
I rolled back a few things in version 1.7.3 that might have interfered with Tampermonkey, it would be great if someone with the issue could check if this changes anything
You can always roll back in case of problems.
After installing 1.7.3 initially it didn’t work. But then I remembered, that I didn’t have Tampermonkey, but Greasemonkey. After switching to TM it works.
Works for me now as well. Thanks for this great script by the way, very useful.
For the record,
GM_getValue() completely trips Firefox when used with the optional default value.
I’ve got a strange problem with radicals appearing to misbehave:
@valeth has been kind enough to update his dark theme to fit your script
On the radical page for 申 only the phonetic has no link.
On the kanji page for 叔 both radical and phonetic have none.
@jbradleyc @valeth For the radical this is the intended behavior, because not all of the phonetic components have radicals in WK. For the example, there is no “uncle” radical, so the empty box shows that there is no associated radical (yet?). I made the “header” with green, blue, pink elements always the same that you can see more easily what is actually in WK (if the pink kanji are “grayed out” with a checker box background they are not in WK).
I could add some classes to make the styling easier, at the moment everything is placed in a
.wk_keisei or or
wk_niai container, the classes/ids for the WK styling are mostly the same, I added the
phonetic class for the character items.
For Niai in the lessons I think I had to do some kind of magic by wrapping everything into an additional container and also moving WK content there because WK uses a ridiculously strong selector (like three nested ids) for the styling there.
Edit: I’m rather worried why there is an excessive space between the 3 “header elements” and the rest of the phonetic compounds in your screenshot
I think it’s always been like that, and outside of the Breeze Dark theme recoloring it I don’t believe anything else is modifying it at all. I’m using Chrome on Windows 10 with a 1920x1080 monitor.
I can test on Chrome/Win10 later. The layout consists of two elements, and the left one has a fixed with to only leave a small gap …
How does it look like when there are many elements, like for 方 or 者?
It looks better, but oddly inconsistent… 2 vs 3 rows.
Also I think there’s a script to always display the text instead of making it hover-over only… think I’ll go find that lol.
The style makes the boxes wider, so they start wrapping earlier, maybe the widths get mix up as well.
It should be like that:
I should think of a more robust layout
Seems like a good opportunity for flex boxes
True. I would definitely suggest flex boxes in this type of situation.