vimium
vimium copied to clipboard
`p` and `P` generate search URLs with empty query
Describe the bug
The keys p
and P
produce search URLs with an empty query. For example, if "dog" is in your clipboard, pressing p
should open Google's search result for "dog" (https://www.google.com/search?q=dog). However, it instead opens a search URL with an empty query (https://www.google.com/search?q=), and then redirected to Google's top page. The same happens if your clipboard contains a URL and even if you change the search engine to Duckduckgo.
To Reproduce Steps to reproduce the behavior:
- Copy an arbitrary text
- Press
p
orP
Browser and Vimium version
- Chrome: 105.0.5195.102 (Official Build) (64 bit) (cohort: Stable)
- Vimium: 1.67
Hi. I've had the same issue for these few weeks, and just searched for the cause.
This is caused by failure to paste the clipboard content to the textArea
in document.execCommand("Paste");
.
Though after trial and error, I'm not sure how to fix it...
https://github.com/philc/vimium/blob/2c93c251118b43f447dbd0704f1ab04db466e2fd/lib/clipboard.js#L22-L33
BTW, sometimes p
and P
work when I open Vomnibar and close it just before using these keys.
I mean, opening Vomnibar, inputting some characters there, closing it by pressing ESC
, and then pressing p
/P
.
Regardless of the pasting results, document.execCommand("Paste")
always returns true
.
I wonder whether it's a bug of Chromium.
- Chrome: 105.0.5195.102 (Official Build) (64 bit) (cohort: Stable)
- Vimium: 1.67
I'm having the same issue. Chrome Version: 105.0.5195.102 (Official Build) (arm64)
Looks like a problem with the same version of chrome browser.
Same is happening with Brave version 1.43.89, which is running Chromium version 105.0.5195.102 (64-bit)
same thing happening. Windows 10 Chrome Version 105.0.5195.102 (Official Build) (64-bit). shitf + p opens new tab with URL: "https://www.google.com/search?q="
I think
document.execCommand("Paste")
is the one causing issue. according to caniuse.com it is still supported?
I thought of Clipboard_API. But it is async and requires permission of user to take clipboard.
const value = await navigator.clipboard.readText().then((clipText) => {
// return clipText.replace(re, " ");
return clipText.replace(/\xA0/g,' ');;
})
return value
I've made a fork of Vimium. It's using Clipboard API instead of execCommand. It works well. At the first time you do the paste through Vimium, you need to allow access to the clipboard, though. https://github.com/NI57721/vimium/commit/6c5b47f2b79be7f75acea9693b76a20fa1c05a7c
If this is applied, we probably should also replace execCommand("Copy") to the alternative of Clipboard API.
@smblott-github Can you help to fix this issue?
Can confirm started seeing behavior for chrome since an update: Version 105.0.5195.125 (Official Build) (x86_64)
Can confirm with Version 105.0.5195.102 (Official Build) (x86_64)
It looks like p
and P
start working again after updating Chrome to 106.0.5249.119 (64 bit). Can anyone confirm it?
It looks like
p
andP
start working again after updating Chrome to 106.0.5249.119 (64 bit). Can anyone confirm it?
I experienced this issue on Chrome 106.0.5249.91 (64 bit)
(last checked version)
I can confirm that it is resolved with Chrome 106.0.5249.119 (64 bit)
:tada:
Reproduced on Chrome 106.0.5249.103 (64 bit) on Win11.
Not working for me too for the past couple of weeks. chrome Version 105.0.5195.125 (Official Build) (64-bit)
works for me again, 106.0.5249.119 (Official Build) (arm64)
. So seems Chrome fixed their regression
It seems to have been fixed in 106.0.5249.119 🎉 we still need to change the way to use clipboard for Manifest V3, though. Log - 106.0.5249.103..106.0.5249.119 - chromium/src - Git at Google
Works for me again, too Chromium: 106.0.5249.119 (Official Build) (64-bit)
This should be fixed permanently by #4122, which is now merged (but not yet released to the store).
Thanks! But I am still seeing this in Firefox. If I press p
, a new tab opens with https://www.google.com/webhp ...