Matching URLs and contexts for single page style web apps

Plugin Development
1

Hello, I’m not sure if this is an issue or if I’m doing something wrong, but I’ve run into it with a couple of plugins now.

I’m working on plugins like the Wanikani mode, where I wanted to enter a context when I navigate to a specific page of a site, like /review. With WK, if Lipsurf is active already, it will start the review context when you click “start session”. But the WK site itself does a page load for those reviews.

For sites that don’t do a page load but instead rewrite the URL, is the match regex checked again or does it only check it on a page load? For instance here’s the snippet of plug in code:

export default <IPluginBase & IPlugin> {...PluginBase, ...{
    niceName: "Bunpro",
    description: "",
    match: /.*www.bunpro.jp\/(learn|study|cram)$/,

This won’t get activated when I navigate from https://www.bunpro.jp/users/michiakig to https://www.bunpro.jp/study, instead I have to refresh the browser with Lipsurf on, and then the plug in will get activated.

I’m not sure if I’m doing something wrong or this is a known limitation. Thanks!

1 Like
2

is the match regex checked again or does it only check it on a page load?
Only on page load.

Yes, this is known and actually some other plugins like the Duolingo one work around it.

The best thing to do currently is to watch the “locationchange” event and adjust context accordingly.

function makeLocChangeEvent() {
    window.dispatchEvent(new Event('locationchange'))
}


init(): {
    window.addEventListener('popstate',makeLocChangeEvent);      
    window.addEventListener('locationchange', locationChangeHandler); 
},
destroy() {
    window.removeEventListener('popstate', makeLocChangeEvent);
    window.removeEventListener('locationchange', locationChangeHandler); 
}

Sometimes even then the proper events aren’t fired from the page depending on how they change the URL internally. If these don’t work, you’ll need to inject a script that overrides js methods like history.pushState history.popState.

1 Like
3

nice, I did end up having to inject a script.

I assume something like this is what you meant? monkey patching history.pushState directly from the plugin didn’t seem to have an effect

4

You can’t monkey patch from the plugins’s js context ever because it runs in a sandboxed js environment :slightly_smiling_face:. But listening to some events work.

If listening to the event didn’t work, yes monkey patching like in that SO question is what I was referring to.