Open seanjennings960 opened 2 years ago
Hello, I've updated the first comment in https://github.com/philc/vimium/pull/4000, to address where Firefox 91.6.0esr is different from 91.0-91.5:
It's the bug fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1739929 from Firefox team, and it's imported to make GMail work on it.
Firefox 96+ and 91.6+esr include the above patch, so they do behave differently.
====
BTW, my extension (https://github.com/gdh1995/vimium-c) can not simulate clicking an <a target="_blank">
with ctrl=false and shift=false on Firefox 96, if only the popup blocker
is enabled, but philc/Vimium does succeed. I haven't find the root cause. I really appreciate it if anyone could help. I've found it's because Vimium calls dispatchEvent
during handling a port message.
Here's my attempt at fixing https://github.com/lusakasa/saka-key/issues/335.
Let me first explain my understanding of the issue:
MouseEvent
is sent, with "native click" behavior this should trigger the browser to open up a tab in the background, foreground, new window.This is an equivalent bugfix to https://github.com/philc/vimium/pull/3985.
To me, it seems that
resistFingerprinting
(RFP) is a separate issue (which should only affect the subset of users which have enabled RFP). This is fixed in https://github.com/philc/vimium/pull/4000. I found the Mozilla bugreport to be the most enlightening reading on the subject. AFAIU, enablingresistFingerprinting
is essentially a security measure which causes theUser-Agent
(UA) interface to spoof the Firefox version so that only a subset of Firefox versions are presented to the website. This will causes the UA-based version number check (>96.0) to become unreliable, by reporting (e.g.) v.91.x when the actual version is >v96.0.I still don't understand the
resistFingerprinting
issue deeply enough to prepare a fix. https:/github.com/philc/vimium/pull/4000 seems to add the additional check that firefox version is >91.0,<91.5, which seems perhaps an improvement, but also not 100% reliable in the non-RFP v91.x case. It also seems to make some other changes to the logic for pulling browser version info that I don't understand.Regardless, I think the bugfix in this PR is valid on it's own, as it will fix https://github.com/lusakasa/saka-key/issues/335 for non-RFP-enabled users.
The one distasteful addition here is the duplicate reading of
navigator.userAgent.match(/\bFirefox\/(\d+)/)[1] < 96
in both files touched. Please LMK if there's a good way to avoid this, and I can submit a patch.