Fingerprinting issue

[tirphana]

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:

1. Go to about:config
2. Set privacy.resistFingerprinting to true and ui.systemUsesDarkTheme to 1
3. Go to a random youtube channel and start scrolling through its videos (using half or full page scroll e.g.)
4. 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?

[gdh1995]

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.

[tirphana]

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.

[gdh1995]

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 queryInterval field in Vomnibar Options will decide how frequently Vomnibar responds on your queries.

[gdh1995]

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 .

[tirphana]

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?

[gdh1995]

It's map o Vomnibar.activate noSessions="start"

[tirphana]

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!

[gdh1995]

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)?

[tirphana]

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.

[gdh1995]

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 ?

[tirphana]

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", 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 ?

Also 2-3 seconds.

How fast/slow will it be, after you set queryInterval in "Vomnibar settings" to 50-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.

[gdh1995]

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?

[tirphana]

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.

[tirphana]

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.

[gdh1995]

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.

[gdh1995]

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" ?

[tirphana]

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.

[gdh1995]

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 %s and other query parts
• and Vomnibar query does not end with ,.;")‘’“”。》），；＞

[tirphana]

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".

[gdh1995]

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.

[tirphana]

youtu.be/QoSePh6HyiI

[gdh1995]

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.

[tirphana]

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.

[gdh1995]

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.

[tirphana]

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.

[gdh1995]

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 of autoSelect and it's not false (#144)
• or if autoSelect option is not false, 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!

[tirphana]

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

[gdh1995]

Um, according to the API document of webextensions, there're up to 25 recently closed sessions. Is there a place to increase the limit?

[tirphana]

That's referring to tabs, I'm talking about windows. Yes, have a look at https://support.mozilla.org/en-US/questions/978193

[tirphana]

And for windows, the default is 3.

[gdh1995]

So did you once have 1~3 closed windows and they includes hundreds of tabs ?

Firefox will encode favicons of tabs into base64 URLs (which means 4KB for a simple 3KB icon file), so hundreds of tabs means a very very heavy JSON object (> 1MB). Maybe this is why it's so slow.

But, quite a few commands of Vimium C will access all tabs in a current window, which also means tons of favicon URLs. I'm not sure whether they're also slowed down or not .

[tirphana]

So did you once have 1~3 closed windows and they includes hundreds of tabs ?

Exactly.

so hundreds of tabs means a very very heavy JSON object

Might be, is there a way to test it?

[gdh1995]

A favicon base64 URL is just like this:

This is indeed too heavy to load. Chrome doesn't provide it - instead it allows extensions to build URLs like chrome://favicon/http://www.bing.com/... to refer favicon data.

Added:

1. there seems no way to prevent Firefox from exposing them to extensions.
2. the icon URL of www.baidu.com has 22637 characters ...

[tirphana]

Well, that must be it then. I can easily work around this now that I know what's causing it, but if nothing can be done about it, feel free to close this issue.

[gdh1995]

Then I can add a small timeout like 100ms when accessing the list of recent closed sessions.

BTW, I can add a command to delete such closed windows, but the command itself will take quite a bit time (the API to delete requires accessing session id first). And the command will be Firefox only, since other platforms have no https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/sessions/forgetClosedWindow.

[tirphana]

Btw unrelated, I can't find info on this, but is there a way to bind arrow keys to a Vimium C command? Something like map <c-RightArrow?> ScrollPxRight, or using mapKey perhaps?

[gdh1995]

map <c-right> scrollPxRight

[tirphana]

Thanks

[gdh1995]

Hello, I updated some code about showing favIcons on Vomnibar. Could you test it again?

If it is still too slow when you close a window having dozens of tabs, then there's nothing I can do about this.

Maybe I need to file an issue on https://bugzilla.mozilla.org/. Could you help me do a few tests to collect info?

The test I want to do is (when a hugh window is just closed) to run code in Console panel of "Developer Tools on Vimium C Options":

console.time("one"); void await browser.sessions.getRecentlyClosed({maxResults:1}).then(i=>{console.timeEnd("one"), console.log("test one:", i&&i.length)});
console.time("12"); void await browser.sessions.getRecentlyClosed({maxResults:12}).then(i=>{console.timeEnd("12"), console.log("test 12:", i&&i.length)});
console.time("25"); void await browser.sessions.getRecentlyClosed({maxResults:25}).then(i=>{console.timeEnd("25"), console.log("test 25:", i&&i.length)});

[gdh1995]

Hello, Vimium C v1.96.1 has been released on Firefox Add-Ons, and could you take a try and see whether this still exists or not?

[tirphana]

Hey man, I'm so sorry, I've been on a business trip last couple of months and had no chance or time for looking into any of it until now, hope we can deal with it now.

1 window closed, ~1200 tabs:

one: 111ms - timer ended test one: 1

12: 98ms - timer ended test 12: 12

25: 100ms - timer ended test 25: 25

After restarting Vimium C options and rerunning the tests I get:

one: 138ms - timer ended test one: 1

12: 108ms - timer ended test 12: 12

25: 105ms - timer ended test 25: 25

[tirphana]

Also, some additional things I noticed:

Sometimes (especially when the cpu is loaded more than usual), omnibar will introduce a delay after pressing enter and just stay floating there before doing the search. The worst part is this delay is never constant, sometimes it stops for 2-3sec, sometimes it hangs for good 15sec or more.

I still encounter some logic bugs with AND and OR operators from time to time, the same type I described in posts above (don't know how much you tackled that issue).

With Temporary Containers addon, moveTabLeft and moveTabRight don't seem to work (between different containers).

[gdh1995]

Then I have no ideas about why it costs so much to list and show up to 25 session tabs. The 100ms can not explain the latency of one or more seconds.

About the delay on enter: there're 2 sources:

• when there's new query words which is not searched for yet, Vomnibar will wait for the search result and redo Enter key
• Vomnibar trys to hide itself before it opens a new tab, so that your browser won't cache a snapshot of Vomnibar and show your query history to any people watching your screen

But, both of the 2 sources can not explain such a time span of 15 seconds ...

AND / OR

Are you still using the above working around of o/\s/.../g ? If so, could you remove them and retry again?

During my tests, cstmsrcheng: https://www.google.com/search?q=%s+(inurl%3Afoo+OR+inurl%3Abar) and %s = this part stays AND this part disappears has worked well now. So could you give some new test examples?

different containers

By default the 2 commands will try to skip a group of tabs in a different container, so if move C right from A B C (D E), then the result will be A B (D E) C.

If you don't want this, you may add group=false, like:

map < moveTabLeft group=false
map > moveTabRight group=false

[tirphana]

But, both of the 2 sources can not explain such a time span of 15 seconds ...

I'll post a video next time I catch it, it's usually not 15sec and happens so randomly, that's why I had trouble recording it.

Are you still using the above working around of o/\s/.../g ?

My bad, for some reason I had it commented out, think I was troubleshooting sth unrelated and had to switch it off, but forgot to turn back on, everything's fine now :)

By default the 2 commands will try to skip a group of tabs in a different container

So far I've never seen that happen, they always just lock up in their place if adjacent tabs are in different containers.

you may add group=false

Cool, that works, thanks. One question though, does using that have any privacy implications and is that command supposed to work detached from different containers as you showed is supposed to be by default?

[gdh1995]

I'll post a video next time I catch it

Thanks.

My bad, for some reason I had it commented out, think I was troubleshooting sth unrelated and had to switch it off, but forgot to turn back on, everything's fine now :)

Sorry. I mean I want you to turn it off. The trick should be removed when this bug gets fixed. If you think Vomnibar doesn't work without it, then there must be some unknown bugs existing. So I expect query examples from you.

they always just lock up

Sounds like a new bug.

group=false

No privacy info. I just want to keep tabs of a same container to be near.

[gdh1995]

they always just lock up in their place

Oh I think I've got what you meant. Do you want to move B in (A B) (C D) ? Then moveTabLeft on B should work, but moveTabRight won't unless group=false - this is a feature but not a bug.

[tirphana]

Oh I think I've got what you meant. Do you want to move B in (A B) (C D) ?

Yeah, exactly right, I didn't know that was the intended behaviour by default.

As far as the rest goes, I'll post an update here when I get around to it, I need more testing done for it to be of any use, so let this issue stay open.

[gdh1995]

Um, in this case, maybe I should move all tabs in (A B) into the right side of (C D). How do you think about it ?

[tirphana]

Meh, I think that shouldn't be the default behaviour, but rather a filter perhaps, available to those who want it. I think the behaviour you described above makes the most amount of sense as the default, which is:

By default the 2 commands will try to skip a group of tabs in a different container, so if move C right from A B C (D E), then the result will be A B (D E) C.

But so far, on my end it doesn't seem to work.

[gdh1995]

in the case of abc(de), C should not be in any group, if you want to move it. Have you tested this case?

---Original--- From: @.> Date: Fri, Jan 14, 2022 10:47 AM To: @.>; Cc: "Dahan @.**@.>; Subject: Re: [gdh1995/vimium-c] Fingerprinting issue (#365)

Meh, I think that shouldn't be the default behaviour, but rather a filter perhaps, available to those who want it. I think the behaviour you described above makes the most amount of sense as the default, which is:

By default the 2 commands will try to skip a group of tabs in a different container, so if move C right from A B C (D E), then the result will be A B (D E) C.

But so far, on my end it doesn't seem to work.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: @.***>