search

lusakasa / saka-key

A keyboard interface to the web
https://key.saka.io
MIT License
860 stars 70 forks source link

Use firefox native click behavior in versions >= 96 #338

Open seanjennings960 opened 2 years ago

seanjennings960 commented 2 years ago

Here's my attempt at fixing https://github.com/lusakasa/saka-key/issues/335.

Let me first explain my understanding of the issue:

  1. There have historically been issues with the "Native Click" behavior in the Firefox browser. When a MouseEvent is sent, with "native click" behavior this should trigger the browser to open up a tab in the background, foreground, new window.
  2. However, before Firefox version 96.0, this "native click" behavior did not exist, and as a result Saka Key has worked around this by special-casing the firefox browser and manually triggering the bg/fg behavior.
  3. Firefox version 96.0 (re?)introduced native click functionality, so this special-casing behavior now must only apply to versions <96.0.

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, enabling resistFingerprinting is essentially a security measure which causes the User-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.

gdh1995 commented 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.