Open alerque opened 5 years ago
It appears the UI weirdness is because after compile Firefox depends on know bype-offset locations in that file. Deleting the strings changed the offsets, but replacing them with space strings of the same length actually worked.
This shell script will hot-patch the Firefox install on my system. Your paths might vary.
WARNING: This will mess with files typically installed by a package manager and hence throw system integrity checks off.
#!/usr/bin/env sh
sudo perl -i -pne 's/reserved="true"/ /g' /usr/lib/firefox/browser/omni.ja
See also: Binary Hacking Firefox. This takes a slightly different (and less brutally hackish) approach of extracting that archive, doing the replace on actual text files, then bundling it back up again.
Yep, you can also patch your omni.ja file (I've even been thinking about implementing a way to do that in tridactyl). Thanks for describing the steps here, I'll keep this issue open to make it easy for people to find it :)
Thanks, @alerque.
Your command worked on Arch Linux with Firefox 69, but it is also necessary to clear the start-up cache as explained in your link. So the complete script is:
#!/usr/bin/env sh
sudo perl -i -pne 's/reserved="true"/ /g' /usr/lib/firefox/browser/omni.ja
find ~/.cache/mozilla/firefox -type d -name startupCache | xargs rm -rf
This workaround seems not to work anymore. At least since Firefox 75 on Ubuntu 18.04
I'm on Firefox 75 and Ubuntu 18.04 and it works for me. Are you sure you shut down firefox, cleared your startup cache, applied the patch and only then restarted firefox?
@glacambre Yes I did, multiple times. I use grep with the binary option to recheck and the file is indeed patched correctly with spaces. I even delete the whole cache/mozilla/firefox directory (with firefox closed, of course).
What I want to do specifically is to by C-w to tabclose so that I can close pin tab with C-w. It used to work.
If you save the following HTML document and open it in your browser,
what happens when you press a keybinding owned by firefox but not by
Tridactyl (e.g. <C-t>
, provided that you didn't bind anything to that
in Tridactyl)?
@glacambre Thanks for the quick reply. So I tried Ctrl-L, Ctrl+C, Ctrl+V which are keys that I unbound all/don't have conflicting tridactyl bindings. I see a bunch of {"isTrusted":true} appears. So I think the patch is kinda work but not for Control+W?
So I think the patch is kinda work but not for Control+W?
I don't think this is possible. I would say Tridactyl probably mangled
your config. Have you tried manually re-creating your binding with
:bind <C-w> tabclose
?
@glacambre I tried that but it didn't work, I also try:
unbind --mode=normal <C-w>
unbind --mode=visual <C-w>
bind --mode=normal <C-w> tabclose
bind --mode=visual <C-w> tabclose
Now I notice that in the test you provide the "istrusted" thing would appear right away whenever I press Control or Alt (or pretty much anykey), but not always for the second key in the combo.
For example, when I press C-w, an "istrusted" will show for Control, but not for w. But for C-l, 2 "istrusted" will show for each key.
@glacambre I figured it out. If you have your firefox profiles directory is outside of ~/.mozilla/firefox/, the the startupcache directory will be located in there instead of ~/.cache/mozilla/firefox.
This is working for me on Arch Linux / Firefox 87. Is there anything to be done to keep this up to date? Does it get reset on version bumps? @tindzk, you're on Arch. Do you use a pacman hook?
Thank you all so much for this btw. You have no idea how many times I've closed a tab with
Yes this gets reset every time Arch bumps the Firefox package either for version updates or rebuilds. You can see the script I'm still using here. I don't have it setup on a pacman hook, although I probably should because every once in a while I miss seeing Firefox update and end up loosing dataa by hitting CtrlW while editing something in a text area. If somebody has a hook file setup I'd be happy to copy it ;-) Or perhaps I should make this script an AUR package that installs the matching hook ... would that get used by anyone?
I know! Firefox blowing away all your data with C-w is so annoying. That's almost better than having nvim in the browser is that firenvim intercepts C-w now. Honestly, this has changed my life.
I actually did look through the aur before setting up this patch, but that's when I thought I had to patch the source. I'd probably still use your aur package anyway if you're willing to set it up. Honestly, sharing a hook in this thread is probably fine too.
Maybe this? Can't think of a nice, concise way to get the user home directory so I hard-coded it, but.
[Trigger]
Operation=Install
Operation=Upgrade
Operation=Remove
Type=Package
Target=firefox
[Action]
Description=Re-apply glacambre/firefox-patches
When=PostTransaction
Exec=/bin/sh -c 'perl -i -pne 's/reserved="true"/ /g' /usr/lib/firefox/browser/omni.ja && find /home/marcel/.cache/mozilla/firefox -type d -name startupCache | xargs rm -rf'
I can't put a hook in the AUR with a hard coded user home path ;-) People will just have to adapt their own unless we find something better. There is probably a way to set this up as a user unit instead of a system unit in SystemD, but saving Tokyo from the octopus monster is low on my priority list.
Haha, I know. I put this here for people to copy and adapt, not for you to put in your package. The problem with the user service is that the perl command needs root to edit /usr/lib/firefox
. Since we are already using find
, we should be able to wrangle that command into something that works for all users. /home/*/.cache/...
, but we'd have to change some flags.
There is a way to disable
With vanilla Firefox. Use dconf-editor, navigate to org/gnome/desktop/interface, change gtk-key-theme
option to the String "Emacs"
. The change is effective immediately without restarting Firefox. More enabled keys with Emacs theme:
https://www.gnu.org/software/bash/manual/html_node/Readline-Bare-Essentials.html
Examples:
C-b
Move back one character.
C-f
Move forward one character.
DEL or Backspace
Delete the character to the left of the cursor.
C-d
Delete the character underneath the cursor.
C-a
Move to the start of the line.
C-e
Move to the end of the line.
M-f
Move forward a word, where a word is composed of letters and digits.
M-b
Move backward a word.
C-k
Kill the text from the current cursor position to the end of the line.
M-d
Kill from the cursor to the end of the current word, or, if between words, to the end of the next word. Word boundaries are the same as those used by M-f.
M-DEL
Kill from the cursor to the start of the current word, or, if between words, to the start of the previous word. Word boundaries are the same as those used by M-b.
C-w
Kill from the cursor to the previous whitespace. This is different than M-DEL because the word boundaries differ.
In Emacs parlance, C- prefix is for Control key. M- prefix is for Alt key.
Note that all the key combinations for line editing only works, when the cursor is in a text input field. Outside they would still follow Firefox defaults, i.e. C-w will still close the tab.
Wow nice find @ne9z. This can also be done on the command line:
$ gsettings set org.gnome.desktop.interface gtk-key-theme Emacs
Now I'm on a quest to see if it has a VIM bindings mode ;-)
Can't think of a nice, concise way to get the user home directory so I hard-coded it, but.
Also an update on the pacman hook @MarcelRobitaille and other Arch Linux folks: It turns out that if you hot patch the Firefox executable every time pacman updates in immediately (as is done from a hook) then the executable never gets run in it's unpatched state and you don't need to flush the cache. I think you only need to do that once manually for your user, thereafter just having the hook on the system is enough to keep it running. This AUR package currently installs the hook and it's been 6 months on a half a dozen systems and it's worked without interruption for me across Firefox updates.
Seems that only "Default" and "Emacs" mode are shipped by the GTK3 toolkit. You can define your own keymap for GTK3 text input field. Though that seems to be quite tedious.
https://gramps.discourse.group/t/gtk-gui-option-for-changing-keybindings/4105
This feature may prove to be short-lived, as GTK4 does not support key themes, and Firefox team discussing the port from GTK3 to GTK4:
About deprecating key theme in GTK4, from 2019 https://ol.reddit.com/r/emacs/comments/c22ff1
About GTK4 port: https://ol.reddit.com/r/gnome/comments/tzyr3l
A useful note: in Emacs theme, C-a is redefined from "Select All" to "Home (start of line)". The former, "Select All", is still available via "C-/".
Having to patch the source and then build is prohibitive for a LOT of people. Less than 8 gigs of RAM? Forget it. Slower CPU? Come back in 2 days. Etc.
Also Firefox releases tend to be urgent, and using distro packages that come pre-compiled makes this quick and easy. Having to recompile would leave a lot of people using old versions a lot of the time.
I had a look at the patch to not reserve keys and it looks like they end up in plain text in an otherwise binary blob file
omni.ja
. I'm wondering if we couldn't come up with a way to monkey-patch an already build version of this file to just change those strings. I tried doing this with some perl hackery and got a running version of FF but with all sorts of UI weirdness.Ideas?