Fingerprinting issue
On enabling the anti-fingerprinting option in Firefox, Vimium-C stops displaying dark mode in its UI and starts being incredibly choppy/delayed on some websites (so far I only tested it on youtube).
Steps to reproduce the behaviour:
- Go to about:config
- Set privacy.resistFingerprinting to true and ui.systemUsesDarkTheme to 1
- Go to a random youtube channel and start scrolling through its videos (using half or full page scroll e.g.)
- Open the Vomnibar and conclude it is white
FF 88.0.1, Arch Linux, Vimium-C 1.90.2
Also, unrelated to this issue, I’d like to ask if there’s a way to fix or troubleshoot a delay on the o-activated Vomnibar?
the resistfingerprintering will prevent Vimium C from learn accurate timestamp, so it can not scroll by small+frequent steps as expected. I once wrote a trick to work around it, but according to what you found, the trick failed. Could you try this config on a Windows or Mac OS?
---Original--- From: @.> Date: Mon, Jun 7, 2021 04:33 AM To: @.>; Cc: @.***>; Subject: [gdh1995/vimium-c] Fingerprinting issue (#365)
On enabling the anti-fingerprinting option in Firefox, Vimium-C stops displaying dark mode in its UI and starts being incredibly choppy/delayed on some websites (so far I only tested it on youtube).
Steps to reproduce the behaviour:
Go to about:config
Set privacy.resistFingerprinting to true and ui.systemUsesDarkTheme to 1
Go to a random youtube channel and start scrolling through its videos (using half or full page scroll e.g.)
Open the Vomnibar and conclude it is white
FF 88.0.1, Arch Linux, Vimium-C 1.90.2
Also, unrelated to this issue, I’d like to ask if there’s a way to fix or troubleshoot a delay on the o-activated Vomnibar?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Unfortunately I don’t have any of those OSs easily accessible right now, I might get around to testing them some later time though. Have you tried looking into some of the other FF options related to RFP (referring to sections 4500 and 4600 of https://github.com/arkenfox/user.js/blob/master/user.js)? I believe one of them might pose a valid solution. And my second question still remains. :)
Edit: RFP also affects the "Open multiple links in a new tab" option in that the new tabs open in the current one, instead of next to it.
My working around for resistFingerPrintering still works on my Firefox 88 x64 + Win10.
When resistFP, ui.systemUsesDarkTheme doesn't set related media queries:
line 1443: 1494034 - return "light" with prefers-color-scheme (see 4617) (FF67+)
So Vomnibar can not know "it should be dark".
As for Vomnibar initing or working slowly, some issues may be useful: https://github.com/gdh1995/vimium-c/issues/291#issuecomment-785692828 and https://github.com/gdh1995/vimium-c/issues/26 :
- the command option of
noSessions="start"will make it not show closed tabs on a first showing - the
queryIntervalfield in Vomnibar Options will decide how frequently Vomnibar responds on your queries.
Um, since Vomnibar uses a timer to decide when to refresh, resistFP does harm it.
the 100ms is even not configurable - https://developer.mozilla.org/en-US/docs/Web/API/DOMHighResTimeStamp#reduced_time_precision .
So Vomnibar can not know "it should be dark".
Alright, thanks for clearing that up.
Um, since Vomnibar uses a timer to decide when to refresh, resistFP does harm it.
I’m having Vomnibar delay issues with RFP disabled.
* the `queryInterval` field in Vomnibar Options will decide how frequently Vomnibar responds on your queries.
This doesn’t seem to make a difference, since the delay is present on opening it. (same as in #291)
* the command option of `noSessions="start"` will make it not show closed tabs on a first showing
When I insert map o Vomnibar noSessions="start" to custom key mappings, I get a Command "Vomnibar" doesn't exist!. error. Am I doing something wrong here, or am I supposed to place it somewhere else?
It's map o Vomnibar.activate noSessions="start"
Now it works, and it stopped the delay, thank you. So far the RFP goes, considering the nature of the problem, I will not inquire about it any further, and as far as I’m concerned you can close this issue. Cheers!
But as far as I can imagine, the noSessions only reduces 1~10ms...
Will the delay occur (only during a first Vomnibar) again if you restart your browser (or the whole computer)?
Well, I had a delay of 2-3sec, and with noSessions I have none. And yes, it persists after the browser restart and a reboot, even reinstalling the addon did nothing.
Hello, I want you to help do 2 tests:
If map o Vomnibar.activate (without noSessions), press o, wait for Vomnibar showing, press <esc> to hide it, wait for seconds, and then press o to trigger Vomnibar again.
In this case how long will Vomnibar take to show the second time?
If map o Vomnibar.activate noSessions="start", press o, type some letters on Vomnibar, and then delete all letters.
In this case Vomnibar should show recently closed sessions when the query becomes empty. So will sessions show quickly, or also in 2-3 seconds ?
How fast/slow will it be, after you set queryInterval in "Vomnibar settings" to 50-100 ?
If
map o Vomnibar.activate" (without noSessions), presso, wait for Vomnibar showing, press ``to hide it, wait for seconds, and then presso` to trigger Vomnibar again. In this case how long will Vomnibar take to show the second time?
I assume you meant "press Esc to hide it", and when doing that Vomnibar takes the same as in the first time (2 or 3sec approx.)
If
map o Vomnibar.activate noSessions="start", presso, type some letters on Vomnibar, and then delete all letters. In this case Vomnibar should show recently closed sessions when the query becomes empty. So will sessions show quickly, or also in 2-3 seconds ?
Also 2-3 seconds.
How fast/slow will it be, after you set
queryIntervalin "Vomnibar settings" to50-100?
I set it to 75, and it made no difference in the opening and sessions delay. QueryInterval is however visible when I compare 1 and 1199, for example, but only in the speed of suggestions while I type.
So, on your computer, some code using browser.sessions works unexpectedly slow. I have no idea about why.
Does this still happen if disabling resistFP, or even in a fresh Firefox profile?
Yes, it happens with RFP disabled, and all other configs left as default.
There’s no delay on a fresh FF profile, but what I noticed it is, after normal usage on a fresh profile (literally browsing youtube, wikipedia, github, reddit) for a couple of days, it goes back to introducing a delay, with no appearent cause.
Also, since I derailed this thread already, might as well ask without opening a new one why Vimium C swallows the closing bracket if the custom search engine command ends with it. For example, if cstmsrcheng: https://www.google.com/search?q=%s+(inurl%3Afoo+OR+inurl%3Abar), then there will be no bracket after "bar" when opening the search. I tried putting 2 brackets in the end to combat this, but after doing that, I noticed that my "%s" search term would get swallowed sometimes for no reason. Also tested it in philc’s Vimium, and there was no such problem. If you can confirm this isn’t just on my side, I’d be glad to have it moved to a new seperate issue.
Sad, if no ) then it seems a logic bug.
by default, Vimium C thinks ) "after a copied URL" is just a mistake - when a user select a URL in ( and ), maybe the caret goes too right. So it always removes it.
Then I'll try to fix this in a next version of Vimium C.
I think there should be a working around in current versions. Let me look at the source.
after normal usage on a fresh profile
Does this occur on a fresh profile "after viewing only 10-20 tabs and closing them", but not "after a few days" ?
I think there should be a working around in current versions. Let me look at the source.
Alright.
Does this occur on a fresh profile "after viewing only 10-20 tabs and closing them", but not "after a few days" ?
It doesn’t. Usually it takes between 3-5 days, and during that time I go through way more than 10-20 tabs.
Does the search engine of cstmsrcheng: https://www.google.com/search?q=%s+(inurl%3Afoo+OR+inurl%3Abar) support: ?q=(inurl%3Afoo+OR+inurl%3Abar)+%s ?
In a current version Vimium C always treats Vomnibar query as "copied text", so it applies too many conversions to it . I'll fix it in the future.
Fortunately the fix only applies on the tail character (and some head characters), so it should work if:
- switch
%sand other query parts - and Vomnibar query does not end with
,.;")‘’“”。》),;>
Does the search engine of
cstmsrcheng: https://www.google.com/search?q=%s+(inurl%3Afoo+OR+inurl%3Abar)support:?q=(inurl%3Afoo+OR+inurl%3Abar)+%s?
It does, but only if the %s is a word or a combination of them. If %s = this part stays AND this part disappears for example, then after the AND operator, the whole URL is copied to the Vomnibar field and if you don’t immediately switch to a "+" instead of " ", everything after the given operator gets swallowed. Obviously this doesn’t apply to just "AND", but to a host of other operators of which I’ve so far only bothered to check "OR" and "NOT".
the whole URL is copied to the Vomnibar field
Um, what did you mean in this line? Could you provide an example of real Vomnibar query & suggestion text & opened URL ? And screen snapshots may help.
youtu.be/QoSePh6HyiI
Oh I see. Sorry for this annoying bug.
I survived in finding a working around: add such rules to the advanced option named "Auto substitution of various text"
o/ /+/g
o@^[^:]+://.*$@$0)@
Such rules starting with o means to do text substitution on Vomnibar query when it's opened, and the later is just like the linux command of sed 's/.../.../g' .
The first line replaces spaces with +. The second appends ) to any URL-like query, and then ) will be stripped by Vimium C's inner logic, so the final URL to open will be correct.
Please note that this is too tricky and will break Vomnibar again when a next version of Vimium C fixes this bug.
o/ /+/g o@^[^:]+://.*$@$0)@
It still swallows the operator (AND in the previous example) and malfunctions randomly (sometimes swallows the term before the operator). Also, some sites don’t parse the "+" as a " " in their search field, so they just return irrelevant stuff as a result. I won’t complain though, I understand it’s a temporary fix.
Please note that this is too tricky and will break Vomnibar again when a next version of Vimium C fixes this bug.
Could you just ensure that the fix includes a way to place %s before the parameters term in brackets (as in the original question), instead of having it at the tail ((parameters)+%s)? I’d really like to see the query (in Google, for example) and have the bracketed parameter gibberish stuck to the end, because it goes out of view? Oh, and sorry for the late reply.
place %s before the parameters term in brackets
Of course. In fact Vimium C should not throw any part in Vomnibar query. And I've updated the logic of finding URL in clipboard, to keep text as is if it includes both ( and ) in the same time.
swallows the operator (AND in the previous example)
A bit strange. The first line of o/ /+/g should replace all spaces with "+". Please note that the line has a space character between the two / characters; and you may try o/\s/+/g .
some sites don’t parse the "+" as a " " in their search field
Yes. In such cases o/\s/%20/g may work. You may even prepend some rules like o/\s/%20/g,host=www.bing.com (one host per line) to declare them.
====
Well I'll publish a new release in up to 2 weeks. Sorry for such stupid logic bugs.
A bit strange. The first line of o/ /+/g should replace all spaces with "+". Please note that the line has a space character between the two / characters; and you may try o/\s/+/g .
youtu.be/5qs2g17HH84 . The thing is, sometimes it swallows the whole operator, sometimes both the operator and the part before it, sometimes it just leaves the first letter of the operator and sometimes it works as expected, while I’m just sitting here confused :D
o/\s/%20/g,host=www.bing.com
That’s cool, I didn’t know I can limit by domain
Well I'll publish a new release in up to 2 weeks. Sorry for such stupid logic bugs.
Sure, but please leave this issue open for some time, I think I figured out what’s causing the Vomnibar delay, I just need some days to test and confirm it, then I’ll make a post here if I succeed.
youtu.be/5qs2g17HH84
Um, I think it works as I expect. It seems you misunderstood how Vomnibar deals with your queries:
- if there's a selected suggestion (with a background color of dark blue), then Enter opens the suggestion
- if there're no selected suggestions then the input bar is "selected", and Enter opens query words in the input bar as a "URL, or search command (engine + words), or plain search words"
- if you press Down to move the "Vomnibar's selection" from the input bar to a suggestion, then Vomnibar shows the suggested URL in the input bar
- if you press Up and there's no selected suggestions, Vomnibar will show your queries back
- if you edit a suggested URL, then the modified URL becomes new "query words"
- as a result, Enter will only use the modified URL, but not a new "first suggestion"
You may have found sometimes Vomnibar will select a first suggestion by default. This is enabled:
- if your query is a search command (engine + words)
- or if in your key mapping,
Vomnibar.activate***has an option ofautoSelectand it's notfalse(#144) - or if
autoSelectoption is notfalse, and the mode of Vomnibar only includes one "engine", like bookmarks, history, or tabs
, I think I figured out what’s causing the Vomnibar delay
Thank you for your patience and help!
Thank you for your patience and help!
The issue was apparently that I had a lot of tabs (from 300 to 500, depending on when) stored inside the "Recently Closed Windows" section of firefox, and it was slowing down the sessions code you mentioned earlier. After I removed the saved window entry from there, the delay immediately stopped. I don’t know what exactly is causing it, but I found a recent firefox bug report that seems to be somehow related to sessions and "Recently Closed Windows", so you might want to look into it: https://bugzilla.mozilla.org/show_bug.cgi?id=1715761
Um, according to the API document of webextensions, there're up to 25 recently closed sessions. Is there a place to increase the limit?
That's referring to tabs, I'm talking about windows. Yes, have a look at https://support.mozilla.org/en-US/questions/978193
And for windows, the default is 3.