If a page refresh occurs the entire page will be reset, and tampermonkey will re-run all scripts from the start. Any scripts executing on the previous instance of the page will be terminated before the new one starts loading, so a refresh shouldn’t affect your script.
That would be one option, I wonder how that would happen though. Tampermonkey should prevent double installations. By default, if a script is already installed and you try to install it again, it will reinstall instead of add, so you’ll still be left with a single instance. I don’t know what the behavior would be with 2 script managers though, although I assume that would give problems during installation too. It’s quite hard to get a double install by accident
But possibly less difficult than inserting the section twice while only logging to the console once.
@AlexandraIDV: These are the only further debugging steps I can think of:
Open the Tampermonkey dashboard and check that:
only three scripts are loaded: Tofugu Latest, Wanikani Double Check, and Wanikani Stroke Order
Open all three in the dashboard editor and ensure they contain the correct script (and not a redundant copy of the Tofugu Latest script somehow).
Check the currently loaded extensions in Firefox. This should be under the Tools menu, Add-ons and Themes. I think it’s accessible via CTRL-Shift-A on a PC. Ensure that only Tampermonkey is currently enabled.
Maybe check for the latest version of Firefox and upgrade if required.
Hopefully, one of these steps will uncover the problem.
Would it be possible to use this script for other websites? There’s a website I can’t get an rss to work for, so I’m wondering if it would be simple to just swap out simple stuff with this script. I don’t code, so my apologies if this is a bad question.
I just posted version 0.3 with the following fixes:
Clicking on the logo now takes you to the tofugu.com home page (requested by @polv)
It now displays better on smaller screen sizes (also requested by @polv)
Unfortunately, two other outstanding feature requests have not been implemented. I need to ponder if they are feasible and worth the effort of implementing.
@TofuguSayaka pointed out that the script only retrieves new articles to the blog by date. In particular, this means it does not notify of updates to the Japanese Grammar section of the Tofugu site, which is extremely unfortunate. Unfortunately, the script just grabs the RSS feed provided by tofugu.com. Like many blog sites, they don’t currently update the feed for “static” pages, only for the blog section. I will reach out to Tofugu to see if they can update the RSS feed on major updates to the grammar section (or at least create a blog entry when they do so).
Currently this has the RSS feed for tofugu hard coded (Tofugu). @DIO-Berry asked if it could be extended to support arbitrary blogs. Unfortunately, for security reasons all modern browsers prohibit cross-origin resource sharing. Basically, your browser won’t let a script provided by the wanikani.com domain access resources on a different domain unless it’s expressly allowed by the admins of the other domain. The fine folks at tofugu.com added such permission at my request, but other domain administrators are unlikely to add the required exceptions. There are workarounds involving local proxies and such, but they are far too much of a headache to implement.
Lastly, please note that there is a problem when using this script with the Breeze Dark user style: the visited state does not display correctly.
Odd. I must have screwed up the CSS. It’s supposed to take 20% of the available space, with 10px of padding all around. I can only simulate in Chrome where it renders correctly (as shown above).
What model of Android phone do you have? (Or at least the screen dimensions)
Interesting. I only did limited testing using the Pixel 5 and iPhone presets in Chrome (minimum width: 393px). They all looked fine.
Anything under about 380px and it starts to fall off a cliff, though, due to the 10 px padding on each side.
Please do me a favor and manually reduce the padding applied to the <a> wrapping the <img> tag. I think 3px per side probably suffices for screens less than 400px, but I’d like to verify before pushing the change.
It now displays reasonably well down to screen widths of about 285px wide. I’d rather not support anything smaller than that if I can avoid it (though if it does become necessary, I’ll write conditional CSS layout to move the logo to the top at small screen sizes).
Current behavior:
Above 400px screen widths, it displays the entire title of each article with 10px of padding surrounding the logo.
Between 380px and 400px, it displays the first 15 characters of the title minus room for an ellipses, and drops the logo padding to 3px.
Below 380px, it displays the first 10 characters of the title, and keeps the logo padding to 3px.
I’ll wait for a better time then
thanks for keeping me updated and explaining at least
