I’m the main developer of VimFx. VimFx is all about single-letter keyboard shortcuts. There is a slight conflict between VimFx’s “go to previous/next tab” shortcuts and NoScript’s “ClearClick rapid fire” protection.
Both I and some of VimFx’s users regularly bump into this issue, and we’ve done so for several months. The reason I haven’t reported this until now is that I haven’t been able to find steps to reproduce until yesterday. Before that I couldn’t know if it’s VimFx’s fault or NoScript’s fault (or perhaps both), but now I’m pretty sure it’s a minor quirk in NoScript that’s the culprit.
At a glance, the steps below might look too complicated and like a weird edge-case nobody ever runs into. However, we do experience the problem every now and then, and the below steps might be just one way of triggering it.
Here we go:
- Create a brand new Firefox profile. I’ve tested in Firefox 43.0.4 and in Firefox 47.0a1. The problem is only reproducible if multi-process is turned off.
- Install NoScript 2.9.0.3 from AMO. (When I did this, the most recent development build was 2.9.0.3rc1, which is older than the stable build, so I didn’t bother trying it.)
- Install VimFx 0.12.0 from AMO.
- Go to VimFx’s settings page in the Add-ons Manager.
- Scroll down to text input labeled “Previous tab” and with the contents “J gT”. Change the contents to “J gT q”.
- Below the above text input there is another text input labeled “Next tab”. Change its contents from “K gt” to “K gt e”.
- You should now be able to press “q” to go to the previous/left tab (like pressing ctrl+shift+tab), and “e” to go to the next/right tab (like pressing ctrl+tab).
- Open https://noscript.net/ in one tab.
- Open https://www.mozilla.org/en-US/ in another tab.
- Close the Add-ons Manager tab, leaving you with only the noscript.net tab and the mozilla.org tabs open.
- Focus the mozilla.org tab.
- Perform the following sequence. Note: If you do it super quickly, or super slowly it won’t work. But if you do it in a “normal” speed, as if you were browsing the web for real, it’ll happen. Waiting about a second between each step seems to cut it.
- Click on a “dead” area (e.g. not on a link) somewhere on the mozilla.org page.
- Click on the noscript.net tab.
- Press either “q” or “e”.
- Press “q” or “e” several times in a row. The expected outcome is that the current tab should change each time you press one of those keys. The actual outcome is that the current tab changes on every other key press. If you look at the browser console you’ll see this:
Code: Select all
[NoScript ClearClick] Swallowed event keydown on https://noscript.net/ (rapid fire from https://www.mozilla.org in 472ms) [NoScript ClearClick] Swallowed event keyup on https://noscript.net/ (rapid fire from https://www.mozilla.org in 591ms) [NoScript ClearClick] Swallowed event keydown on https://www.mozilla.org/en-US/ (rapid fire from https://noscript.net in 479ms) [NoScript ClearClick] Swallowed event keyup on https://www.mozilla.org/en-US/ (rapid fire from https://noscript.net in 607ms) [NoScript ClearClick] Swallowed event keydown on https://noscript.net/ (rapid fire from https://www.mozilla.org in 479ms) [NoScript ClearClick] Swallowed event keyup on https://noscript.net/ (rapid fire from https://www.mozilla.org in 599ms) [NoScript ClearClick] Swallowed event keydown on https://www.mozilla.org/en-US/ (rapid fire from https://noscript.net in 576ms) [NoScript ClearClick] Swallowed event keyup on https://www.mozilla.org/en-US/ (rapid fire from https://noscript.net in 695ms)
- The problem is not tied to those specific sites, and not to just having two tabs open. I just tried to be very specific in the steps above.
- The problem is not limited to just “q” and “e”. For example “s” and “h” also work. The reason I chose “q” and “e” is because those letters are unused by VimFx by default, making the steps to reproduce simpler.
- After NoScript has swallowed a keydown event, pressing any key seems to move to the next tab.
- To get out of the “NoScript swallow mode” you can for example scroll the page a little.
- A workaround for VimFx users is to noscript.clearClick.rapidFireCheck to false.
If you think that VimFx should change something in its code base, please say so and I’ll do it.
Since the problem does not occur in multi-process Firefox, another solution could be to simply tell VimFx users to set noscript.clearClick.rapidFireCheck to false until multi-process Firefox lands in stable releases and NoScript has full multi-process support. If so, I would be more than happy if somebody could help me explain to VimFx users exactly what protection they loose if the set noscript.clearClick.rapidFireCheck to false.
Thanks for reading and a for a great add-on!