Recently every browser changed its URL bar behaviour. When you click into the address bar, it selects the whole URL.
I’m a web developer, so most of the time I just want to edit a parameter in the URL or add to it. This auto-selection behaviour is painful. I aim my pointer exactly where I want the cursor to be, click it, and the whole URI is selected, so as soon as I start to type, everything gets deleted.
Is there any way to revert the “clickSelectsAll
” behavior on Firefox?
Best Answer
Firefox, March 2020 and later
Around March 2020, the
browser.urlbar.clickSelectsAll
preference has been removed. Since then, this bug has been under discussion, where a patch has been suggested — this would involve recompiling Firefox from scratch.As the “
clickSelectsAll
doesn’t work” duplicates accumulate on Bugzilla, one of these has received a comment by Stephen McCarthy which describes a workaround that involves editing internal Firefox files, specifically theomni.ja
which basically is azip
file that contains lots of internal files, e.g. JavaScript modules for the browser chrome, including the relevantmodules/UrlbarInput.jsm
. This workaround looks like the simplest approach, but the approach doesn’t work as-is.There is an official documentation on MDN that describes how
omni.ja
should be repackaged. I also found a blog article on Shallow Thoughts about modifyingomni.ja
that describes this process in more detail. Then, there is another thing to worry about: you need to force Firefox to use the modifiedomni.ja
by clearing its startup cache, which is explained in an In Pursuit Of Laziness blog article that I found.Modifying internal files
Puttng all these resources together, these are the shell commands that currently work on Arch Linux (
core/linux
5.8.1.arch1-1
through5.10.4.arch2-1
) with either Firefox Nightly 81.0a1 (2020-08-20) through 86.0a1 (2021-01-10) (64-bit) or Firefox ESR 78 (64-bit) (probably).1 If at any point you run into “permission denied” errors, simply continue executing the commands as root. These need to be executed after every Firefox update. The commands are explained afterwards.Instead of typing the individual commands, you can use this shell script instead, available on this GitHub repo of mine. That script offers a user-friendly terminal interface; it automatically finds Firefox, changes the
omni.ja
and handles the cache. It also automatically switches to root as needed and creates backups.The commands
Important notes:
Update Firefox and then close it before doing this. Firefox needs to have the updates installed (i.e. you may have to start Firefox after upgrading, then close it again).
/usr/lib/firefox
is a possible install path for Firefox; your path may differ, e.g. it may be/usr/share/firefox
. You should be able to find the possible paths with one of these commands:The correct
omni.ja
is in the…/browser/omni.ja
path.Before any of this is executed make sure you create a copy of the working
omni.ja
somewhere, so you have a backup available in case something goes wrong.Make sure you replace
⟨user⟩
by the user name and⟨group⟩
by the user group of the original ownership of the file. As far as I know, in most cases, this should beroot:root
, if it isn’t already.After unzipping
omni.ja
you may want to double check thatthis._preventClickSelectsAll = this.focused;
exists inmodules/UrlbarInput.jsm
, andthis._preventClickSelectsAll = this._textbox.focused;
exists inchrome/browser/content/browser/search/searchbar.js
.Clearing the cache
Finally, Firefox needs to properly load the new
omni.ja
by purging the cache. These are the two different options I found easiest. Only one of the options is necessary.One way to do that is to simply create an empty file named
.purgecaches
in thebrowser
directory. For example, you can execute this:You’ll only need to create that file after running the above commands. On startup, Firefox will clear its startup cache if it finds this file, and it will also attempt to remove the file. Depending on how you originally installed Firefox, removing the file automatically may fail. Even if that doesn’t affect successfully clearing the cache, just be aware of that.
An alternative way is to find the desktop configuration file for Firefox. Look into
/usr/share/applications/
or~/.local/share/applications/
and find some*.desktop
file withfirefox
(ornightly
or maybemozilla
or something similar) in the file name. Open the files you found. On my system there are two of them:firefox-bin
(viaExec=
)/usr/lib/firefox/firefox
You want to modify the larger one: after each
/usr/lib/firefox/firefox
(or whichever path it is for you) put the-purgecaches
option (--purgecaches
works, too); so one of the configuration entries may looke like this:Using this approach, you may need to edit your
*.desktop
file after every Firefox update and it slows down every start-up of Firefox.Now you can start Firefox by clicking on the desktop icon.
There are two other alternatives, if you don’t start Firefox from clicking on the desktop icon, but instead use the terminal:
firefox -purgecaches
into the terminal,export MOZ_PURGE_CACHES=1
into the terminal, then typefirefox
into the same terminal.And finally, you can clear the cache directly, as well. The script caches, including the startup cache, are hidden in the
.cache
directory of your/home
. The path will look something like/home/⟨user⟩/.cache/mozilla/firefox/⟨profileID⟩.⟨profileType⟩/startupCache
. Deleting these directories will clear the startup cache of Firefox.Use this approach if you use more than one profile on the same Firefox installation. The other built-in
purgecaches
approaches only clear the cache of the first profile that gets used by Firefox.Explanation
First, these lines unpack the
omni.ja
file (a quasi PKZIP file) into the newly created/tmp/omni
directory using theunzip
utility (extra/unzip
6.0-14
).-d omni
just extracts the files from/usr/lib/firefox/browser/omni.ja
into the/tmp/omni
directory;-q
suppresses output (just a list of files being inflated and extracted).unzip
will exit with status2
and you’ll get a warning and an error like this when running theunzip
command:Don’t worry about it. This doesn’t affect the process; status
2
just means that some error was detected, but “[p]rocessing may have completed successfully anyway”, as the man page says.Next, these two lines edit the appropriate files in-place. The
_preventClickSelectsAll
property controls if selection happens on a single click. Setting it totrue
will prevent this behavior. The first line addresses the URL bar, the second line addresses the search bar.This creates a new
omni.ja
with the changed file using thezip
utility (extra/zip
3.0-9
).It’s important to target
*
(every file) insideomni/
, not theomni/
directory itself; we don’t want to create anomni.ja
withomni
as the root directory. Getting in and out of the directory withcd
also ensures the correct file hierarchy, otherwise,zip
would still include the additionalomni
root directory in the archive.As for the options,
-0
sets the compression level to no compression and simply stores the files;-D
avoids creating entries in the zip archive for directories;-X
does not save extra file attributes;-q
, again, suppresses output;-r
ensures that files are added recursively in their correct directory paths.These are the options recommended in the MDN documentation. You may have seen an older revision (before I edited it) that uses
-9
(-qr9XD
, exactly) instead of-0
, but this causes issues: for instance, the localization of the tooltips that display keyboard shortcuts fails to load within the developer tools. The answer at Possible to modify hardcoded Firefox JavaScript Ctrl-Tab panel behavior? mentions that-0
is thezip
option that creates anomni.ja
file with a file size closer to the original file. Incidentally, that’s the only option that avoids this weird localization issue. I explain this in detail in this GitHub issue.Next, the created
omni.ja
is moved to the Firefoxbrowser
directory (and it replaces the file; don’t directly use an existingomni.ja
as thezip
target, or else the files will be nested into the existing ZIP), the permissions can be set like the original file, and in the end you can remove the/tmp/omni
directory.It turns out that the
chown
command may not be strictly necessary, but it ensures that the newomni.ja
has the same owner as the original file. Alternatively, if you copied the original file as a non-root user to a backup directory, you can use this:Of course, you can use another file, like
/usr/lib/firefox/browser/crashreporter-override.ini
as a reference.Restoring an
omni.ja
backup in case something goes wrongIf Firefox doesn’t seem to be running correctly after this process, or not at all, this process didn’t work, unfortunately. You can restore your backup by a simple
mv
like this (possibly as root):Remember to purge the caches once again.
If you didn’t create an
omni.ja
before, you need to re-download Firefox and extract the package to find a replacementomni.ja
.As an aside, the suggested workaround on Bugzilla has a
zip --update
command. The full commands would be:… and …
Unfortunately, even with the knowledge about
zip
file hierarchy, I can’t get this to work — it would be nice, though, as it would speed up the process a bit. Instead, I get an error like this when starting Firefox:I wonder if Mozilla automatically reports such errors even if I tampered with the build…
Related questions:
1: It will likely keep working for later versions, and it probably works for older versions, too; I will only update the versions if this post substantially changes.