Erek Speed
Erek Speed
This appears to be due to the isVisible check looking at an invisible rikaichan window in a iframe. Probably solved if we pass ownerDocument to the method.
Or perhaps `window.top` to get the top most frame. But that mgiht not work if the popup comes from a child frame. It might be good to only show popups...
I wonder if we can use the chrome native keyboard API for this now.
I guess not for the popup context ones. the chrome commands API can only be used for global shortcuts (with ctrl/alt modifiers) Still not a bad idea.
Hi Marpe, There are several layers to this issue that are all fairly doable but I've not found time to prioritize. Working on chrome extensions is actually fairly straight forward...
I think it should be doable to add a check to ensure the mouse pointer is inside/near the returned range. Some Ideas: https://github.com/birchill/10ten-ja-reader/commit/34de532f8c7fce0e77f133f7a49883d2f484bd4f
Something similar to this was done for google doc rects so hopefully it can be extended fairly easily.
Other examples is mouse triggering in wani kani when far under the words.
Can be added to contributing guide ala: https://github.com/melink14/rikaikun/issues/183
Incremental workaround for pull requests is mentioned here: https://github.com/stryker-mutator/stryker-js/issues/2843 > `npx stryker run --mutate $(git diff --name-only HEAD $(git merge-base HEAD origin/main) -- "*.ts" ":(exclude)*.spec.ts" | tr '\n' ',' |...