saka-key
saka-key copied to clipboard
"Open Link in Background Tab" opens two tabs instead one
my browser: firefox 96.0b9 (64-bit), linux ubuntu
I think this happened because of the update from firefox 95 to firefox 96. Very unfortunate, makes this extension almost unusable.
This is happening with similar extensions too, might give a hint what the underlying problem is: https://github.com/philc/vimium/issues/3986
Also occurring on Arch Linux, Firefox 96. Can't recall if this was happening before the update to 96, or just after.
Just noticed this issue as well although I'm on nightly 98.0a1. Arch Linux as well. It's probably obvious but worth noting this also happens when you open link in foreground tab as well.
@eejdoowad Could we have fix for it? It's already been fixed in Vimium.
I have a semi fix at https://github.com/lusakasa/saka-key/pull/337. I don't know where to put the userAgentMatch
such that it only gets executed once, when the extension is loaded, rather than every time an event occurs (unnecessary repetition, as the user agent probably won't be changing that often).
It checks to see if the Firefox user agent is >= 96 before applying the fix, as that's about when it broke. But the problem is: I'm on Arch, which has the latest Firefox build available (96). But when I was testing, Firefox was still reporting the user agent string as Firefox 91 (even after a kill and relaunch of Firefox). So the version check isn't effective for me. I tested this with Vimium, which @ris58h above just mentioned has already had this fixed a month ago, and the version check they use also doesn't work for me. The tab duplication persists.
Is this Mozilla's bug, or something I'm missing? I'm not a web developer, so this is new to me.
Nevermind, it looks like the user agent problem is because I have privacy.resistFingerprinting
set to true in about:config
[1]. Disabling it sets an up-to-date user agent. That's going to be yet another problem though, for users that want their privacy. Perhaps a menu option in the extension popup to override the behaviour manually?
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1489903
@Seanld it seems like Vimium has PR for fixing the issue with privacy.resistFingerprinting
https://github.com/philc/vimium/pull/4000
Not sure what's going on with the privacy.resistFingerprinting
, but building off of all the links in this issue and https://github.com/lusakasa/saka-key/pull/337, I may have a fix here: https://github.com/seanjennings960/saka-key/pull/2.
As said in https://github.com/philc/vimium/pull/4000#issue-1118389384,
Firefox will report a version of "91.0" in
navigator.userAgent
, if onlyprivacy.resistFingerprinting
onabout:config
is enabled.
Updated on 2022/08/09: I was still curious about why it's Firefox 96 which began to behave differently, so according to the clue about Firefox 91.6.0esr, today I compared 91.5.1esr and 91.6.0esr and successfully found the root difference.
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. Sadly to learn that complaints from us extension developers didn't make any contribution in it.
Any progress on this issue? It persists on Firefox Developer Edition v105 in Arch Linux as of today