Decode user JavaScript regardless of the existence of whitespace char in it #3944
+1
−3
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is aimed to make user JavaScripts (aka bookmarklets) more stable.
Background
Bookmarklets often contain some URL-unsafe characters like
"
or whitespace char. They are normally encoded by Chrome when you save it, but this behavior is not very consistent. AFAIK Chrome tends to partially leave these chars as they are, especially with relatively longer URLs. For instance I have my own bookmarklet like this:After this bookmarklet is saved once, the URL is now like this:
You can see untouched whitespace char in
javascript:(() => {const enab...
and"
in...element("textarea");t.tex...
while special chars are somehow correctly encoded in the latter half. This should be a buggy behavior of Chrome, but this is what's going on.Why that's problematic for Vimium
In Vimium's Vomnibar bookmarklets with both whitespace chars and encoded chars (because of the reason described above) are not decoded at all before the execution, because it checks the non-existence of whitespace chars before
decodeURIComponent
. I'm guessing this is written to test if the URL has encoded chars, but it's in a wrong way. We can safely get rid of the check becausedecodeURIComponent
is gonna change nothing at all if the original string has no special chars.