Saving a key mapping with a descendant selector in "match" corrupts the space into \u0020
Describe the bug
"Hello, I am trying to create a key mapping to show link hints for all links inside a specific container.
The command I am trying to save in 'Custom key mappings' is:
map <v-repo-links> LinkHints.activate match="#repo-content-turbo-frame a"
Expected result: The command should be saved exactly as written.
Actual result: After saving, the command is corrupted to:
map <v-repo-links> LinkHints.activate match="#repo-content-turbo-frame\u0020a"
This breaks the CSS selector. The same corruption happens when using runKey. This makes it impossible to use descendant selectors in key mappings."
Steps to reproduce the behavior:
Browser, OS and Vimium C versions
- Browser: Vivaldi
- Browser version: 7.4.3684.55 (Stable channel) (64-bit)
- Vimium C version: 2.12.2
- OS name and version: Windows 11 Home, Version 10.0.26100 Build 26100
I will add to this:
Bug: Command parser corrupts JavaScript in openUrl url= parameter
Description
When mapping keys to execute JavaScript bookmarklets using openUrl url=, VimiumC's command parser incorrectly splits the JavaScript code when saving settings, breaking the syntax.
Steps to Reproduce
- Enter the following mapping in Custom key mappings:
map v-test openUrl url='javascript:(()=>{const x="hello";alert(x);})();'
-
Click "Save Options"
-
The mapping becomes corrupted:
map v-test openUrl url="'javascript:(()=>{const" x="\"hello\";alert(x);})();'"
Expected Behavior
The JavaScript code should remain intact after saving, with proper quote preservation.
Actual Behavior
- Spaces are converted to
\u0020in some cases - Double quotes inside the JavaScript are treated as parameter delimiters rather than string literals
- The saved configuration breaks the JavaScript syntax, causing execution errors
Minimal Example
Input:
map v-test openUrl url='javascript:alert("test");'
After save (corrupted):
map v-test openUrl url="'javascript:alert(\"test\");"
Environment
- VimiumC version: [Your version]
- Browser: [Chrome/Firefox/Edge]
- Browser version: [Your version]
Workaround
Using bookmarks with openBookmark title= works correctly as a temporary solution.
Suggested Fix
The command parser should respect quoted strings and not treat internal quotes/spaces as delimiters when parsing the url= parameter.