zunzuncito - TILWolf's humming microblogZola2022-02-13T18:25:11+01:00https://zunzuncito.oriole.systems/tags/til/atom.xmlwolfGetting MPD to parse TIT1 in MP3 files2022-02-13T18:25:11+01:002022-02-13T18:25:11+01:00https://zunzuncito.oriole.systems/17/<p>I have a pretty extensive music library that I manage with MPD, the <a href="https://www.musicpd.org/">Music
Player Daemon</a>. For the longest time now I have also
been aware of <a href="https://beets.readthedocs.io/en/stable/"><code>beets</code></a>, another
management system for music libraries. I played around with it a few times but
never took the plunge to have it organize my entire collection.</p>
<p>A few days ago, whilst looking up a particularly obscure recording, I ended up
finding it on <a href="https://musicbrainz.org/">MusicBrainz</a> and decided to give beets,
which integrates very tightly with that service, another serious try.</p>
<p>Yesterday I finally completed a first rough import of my entire library (which
encompasses about 20,000 songs in 1400 albums). Given the integration with
MusicBrainz, I now try to map every album to a release in their database. If I
can't find it there, I instead fall back to an old favourite of mine,
<a href="https://www.discogs.com/">Discogs</a>. <code>beets</code> will automatically update and
correct any tags once I select the right release.</p>
<p>Whilst importing I decided that I should make more use of the "Grouping" tag as
a way to organize albums into an arbitrary group. This is useful if a series of
media features music that was composed by multiple artists. By matching on the
<em>Haibane Renmei</em> grouping, for example, I can find all music that was made for
that show, without having to keep artist names in mind.</p>
<p>"Grouping" seemed well-supported in MPD, but whilst updating some albums that I
(sadly) only have in MP3 format, I found that MPD would not add the grouping
information to its database.</p>
<p>As per the <a href="https://id3.org/id3v2.4.0-frames">ID3v2.4 standard</a>, the <code>TIT1</code>
frame is used for this kind of information in MP3 files. Sure enough, that tag
was set correctly by <code>beets</code>, and both <code>mutagen-inspect</code> and <code>ffprobe</code> found it.
MPD, however, even though
<a href="https://github.com/MusicPlayerDaemon/MPD/issues/563">this PR</a> had been merged almost
3 years ago, refused to pick it up.</p>
<p>After having the <code>#mpd</code> IRC channel sanity-check my configuration, I
investigated some more. Perhaps my version of <code>libid3tag</code> was outdated. It
wasn't. Perhaps there were some encoding issues, but then why would other tags
from the same file work fine? Couldn't be that either. I hooked up GDB and found
that
<a href="https://github.com/MusicPlayerDaemon/MPD/commit/319c9699fb09e7c35e2aafa022ff8e1f0dcfcd8b#diff-740cf5f8b0a6d5c79ba81c3c4325726dbac10a838f5f704b630f6a8967574b60R320">this line from the PR</a>
was never actually reached at all!</p>
<p>I decided to look a bit closer at how exactly MPD reads tags. The specific
<code>scan_id3_tag</code> function that the PR modified is only called in two places,
<code>plugins/DsdLib.cxx</code> and (indirectly) in <code>plugins/MadDecoderPlugin.cxx</code>. I had
neither of these decoders installed, so... MPD just never got to read anything.</p>
<p>Yet how was I getting <em>any</em> tags, then?</p>
<p>After some spelunking in the decoder plugin folders and with the fact on my mind
that the only decoder I had actually compiled in was
<a href="https://ffmpeg.org/">FFmpeg</a>, something dawned on me. Perhaps it was FFmpeg
that was reading the tags.</p>
<p><a href="https://github.com/MusicPlayerDaemon/MPD/blob/ad4cf79cc967f973f264efe1024f5be1c9a962ec/src/decoder/plugins/FfmpegMetaData.cxx#L75-L94">Indeed it was</a>.
Turns out that FFmpeg does all of the heavy lifting here, and MPD really just
asks it for any metadata and <strong>parses the ones it understands</strong>.</p>
<p>MPD uses "grouping" as a cross-format identifier for grouping information. It
expects that particular string to be a key in the <code>AVDictionary</code> returned by
FFmpeg
<a href="https://github.com/MusicPlayerDaemon/MPD/blob/ad4cf79cc967f973f264efe1024f5be1c9a962ec/src/decoder/plugins/FfmpegMetaData.cxx#L61-L62">here</a>.
Crucially, FFmpeg
<a href="https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/68595b46cb374658432fff998e82e5ff434557ac:/libavformat/id3v2.c#l64">does not expose</a>
<code>TIT1</code> as "grouping" in its metadata conversion table, having MPD drop <code>TIT1</code> on
the floor like a hot potato.</p>
<p>It is debatable where this particular bug should be fixed. I decided to send
<a href="https://ffmpeg.org/pipermail/ffmpeg-devel/2022-February/292948.html">a patch</a>
upstream to FFmpeg, given that more than just MPD can benefit from a fix there.
For the next poor soul I also prepared
<a href="https://github.com/MusicPlayerDaemon/MPD/pull/1439">a PR</a>
that clarifies how exactly MPD reads metadata.</p>
wolfFiltering files in Thunar2021-11-27T17:51:10+01:002021-11-27T17:51:10+01:00https://zunzuncito.oriole.systems/13/<p><a href="https://docs.xfce.org/xfce/thunar/start">Thunar</a>, XFCE's file manager, was a
pretty late addition to my core set of tools that I rely on to accomplish
day-to-day tasks. I started using it heavily maybe 2 or 3 years ago. For the
longest time before that I had been using <a href="https://ranger.github.io/">ranger</a>, a
console file manager.</p>
<p>The ability to move and copy files around between multiple directories using
drag-and-drop is basically Thunar's killer feature for me. I'm often faster
using the mouse to select a bunch of files and then quickly dragging them
someplace else. In comparison, ranger's select-then-yank-and-paste workflow
feels very cumbersome.</p>
<p>However, there's always been a feature in ranger that Thunar did not have - the
very simple but powerful ability to filter the current directory listing by
showing only files matching a given pattern. There's a more or less hidden way
to have Thunar select files matching a wildcard with <code>CTRL-S</code>, but that relies
on popping up an extra dialogue, and doesn't play well with interactive use.</p>
<p>Very early on I found
<a href="https://gitlab.xfce.org/xfce/thunar/-/issues/2">a feature request</a>
for this, but it looked largely abandoned and I forgot about it until today
when, to my extreme surprise, I discovered that it was implemented just 3 months
ago. There does not seem to have been any large fanfare around it; the
changelog
<a href="https://gitlab.xfce.org/xfce/thunar/-/blob/eb2b1b284d08d045cf393bcbf2045965f263d781/NEWS#L65">buries it</a>
in more miscellaneous changes. Not a big deal.</p>
<p>Way more worrisome, however, is that the
<a href="https://gitlab.xfce.org/xfce/thunar/-/merge_requests/136/diffs?commit_id=d6f916eb2b478a49c5b3ba453e773f81154dbd74">commit</a>
implementing the feature does not introduce any user-facing documentation.
Nowhere is explained how the new feature works and what its limitations are. I
had to go read
<a href="https://gitlab.xfce.org/xfce/thunar/-/blob/d6f916eb2b478a49c5b3ba453e773f81154dbd74/thunar/thunar-list-model.c#L2113">the
code</a>
to find out why my search results were littered with seemingly random files in
other directories. Turns out that it consults files in <code>GtkRecent</code> too, merging
results in the current directory with matches of files you had recently opened,
regardless of their location.</p>
<p>A terrible default in my opinion, so I immediately turned it off by disabling
the
<a href="https://gnome.pages.gitlab.gnome.org/gtk/gtk4/property.Settings.gtk-recent-files-enabled.html"><code>gtk-recent-files-enabled</code></a>
property in my GTK config. Thankfully you can still do that, albeit in a
system-wide fashion, but I don't care about recent files.</p>
<p>Still, it's really sad I had to go out of my way to find that out. A less
tech-savvy user could not have done that so easily. It would lower the bar
tremendously here to <strong>describe</strong> what a new feature does and point out <strong>how to
configure it</strong>.</p>
<p>A failure to do so makes software intransparent and hostile, furthers the notion
that the user experience is inherently bad, and very quickly leads to
resignation in the common user base.</p>
wolfproc(5) hidepid=2 and systemd2021-10-27T12:46:24+02:002021-10-27T12:46:24+02:00https://zunzuncito.oriole.systems/12/<p>A couple of days ago I turned on
<a href="https://manpages.debian.org/bullseye/manpages/proc.5.en.html#hidepid"><code>hidepid=2</code></a>
for the <code>/proc</code> mount on my desktop PC. Today I saw the <code>systemd-userdbd</code>
service failing on bootup, and realized that it had been failing to start for a
few days. Aside from the fact that there really should be a well-supported and
easy way to notify administrators of failing units, this obviously needed some
investigation.</p>
<p><code>systemctl status systemd-userdbd.service</code> wasn't very helpful, but <code>journalctl</code>
had the specific error:</p>
<pre><code>[..] spawning /lib/systemd/systemd-userdbd: Read-only file system
</code></pre>
<p>I didn't immediately jump to the conclusion that this had to do with enabling
<code>hidepid=2</code>. After all, why would that result in a read-only file system?
Investigating a failure very early on in boot is a pain, so instead of wasting
my time on that I took to GitHub issues.</p>
<p>As it turns out, <code>hidepid=</code> is just
<a href="https://github.com/systemd/systemd/issues/12955#issuecomment-508490893">not supported</a>
<a href="https://github.com/systemd/systemd/issues/20848#issuecomment-930185888">at all</a>
in systemd. This doesn't seem to be pointed out anywhere, and I certainly was
not aware of it before. Services can set
<a href="https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectProc="><code>ProtectProc=</code></a>,
but there doesn't seem to be a clean way of restricting /proc for unprivileged
users like a global <code>hidepid=2</code> did. I've removed the option for now.</p>
wolfBetter hunk headers with gitattributes(5)2021-08-11T16:41:49+02:002021-08-11T16:41:49+02:00https://zunzuncito.oriole.systems/11/<p>Yesterday whilst catching up on the Git mailing list I stumbled upon this
<a href="https://public-inbox.org/git/20210810190937.305765-1-tsdh@gnu.org/">patch</a>
proposing to improve the hunk header regex for Java. I had never paid much
attention to how <a href="https://git-scm.com/docs/git-diff"><code>git-diff(1)</code></a> finds the
right method signature to show in the headers though I was vaguely aware of a
bunch of regexes for different languages.</p>
<p>Turns out that by default, as explained in the manual for
<a href="https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header"><code>gitattributes(5)</code></a>,
<code>git-diff(1)</code> emulates the behaviour of GNU <code>diff -p</code> and does <strong>not</strong> consult
any of the language-specific regular expressions. This came as a bit of a
surprise to me, as Git usually has relatively sane and extensive defaults. Why
define all these regexes and then not use them by default?</p>
<p>Perhaps one reason is that it is hard to tell when to use which. Git can only
look at the filename, and not all shell scripts share the <code>.sh</code> ending, for
example. Surely it would not be too invasive, however, to define sensible
defaults for, say, files ending in <code>.py</code> or <code>.rs</code>.</p>
<p>In any case I updated my <code>~/.config/git/attributes</code> with the following, and am
now enjoying better hunk headers across the board:</p>
<pre><code>*.c diff=cpp
*.cpp diff=cpp
*.go diff=go
*.md diff=markdown
*.pl diff=perl
*.py diff=python
*.rs diff=rust
*.sh diff=bash
*.tex diff=tex
</code></pre>
<p>The markdown setting is especially neat since it will now display the nearest
section right in the diff, like so:</p>
<pre data-lang="diff" class="language-diff "><code class="language-diff" data-lang="diff">--- a/posts/weltschmerz.md
+++ b/posts/weltschmerz.md
@@ -24,6 +24,10 @@ ## Download
</code></pre>
wolfgit-am(1) and mail sorting2021-07-25T16:58:29+02:002021-07-25T16:58:29+02:00https://zunzuncito.oriole.systems/9/<p>In the <a class="internal" href="/8">previous post</a>
I talked about a couple of
different ways to apply patches with <code>mutt(1)</code> or <code>neomutt(1)</code>. Turns out
<code>Maildir</code> might not be the best format to use for <code>git-am(1)</code> because its
files are not guaranteed to be in any specific order (per
<a href="https://cr.yp.to/proto/maildir.html">spec</a> they need only carry unique names).</p>
<p>As <code>git-am(1)</code> does not sort its input, patches might be applied in the wrong
order. This came up on the mailing list as well, all the way
<a href="https://public-inbox.org/git/20130301222018.GA839@WST420/">back in 2013</a>.
A fix specific to <code>Maildir</code> files created by <code>mutt(1)</code> was added in
<a href="https://github.com/git/git/commit/18505c34237d3544729c3deed3e4f851fb672086"><code>18505c3</code></a>.</p>
<p>Sadly <code>neomutt(1)</code> changed this format 5 years ago, removing the sequence number
that <code>git-am(1)</code> relies on in commit
<a href="https://github.com/neomutt/neomutt/commit/75b3708edb18815935692c60bbae56d5301f8210#diff-8904141e55cf466b09a2db0df752f92a29daf093e79df61121ecd347b7631c19L1489-L1491"><code>75b3708</code></a>
and replacing it with a call to <code>mutt_rand64()</code>. I can only assume no one is
using <code>neomutt(1)</code> to export patches to <code>Maildir</code>, since having patches applied
in the wrong order is a pretty significant problem.</p>
<p>For now I recommend using the <code>mbox</code> format instead when exporting patches.
Whilst that doesn't guarantee a specific order either, usually mail clients are
nice enough to export mails to <code>mbox</code> in the order they are shown.</p>
<p>The core issue remains until <code>git-am(1)</code> learns to sort mails itself.</p>
wolfApplying patches with mutt(1)2021-07-23T22:37:17+02:002021-07-23T22:37:17+02:00https://zunzuncito.oriole.systems/8/<p>When maintaining a project sooner or later there comes the time when you need to
apply patches that have been submitted to you. Assuming a patch-based workflow
those are going to be one patch per mail, possibly connected in a thread.
There's lots of different ways of getting those patches to their final
destination, <a href="https://git-scm.com/docs/git-am"><code>git-am(1)</code></a>, and in this post I
want to take a look at ones that work well with <a href="http://mutt.org/"><code>mutt(1)</code></a> or
<a href="https://neomutt.org/"><code>neomutt(1)</code></a> since that is what I use.</p>
<p><em>I want to rely on the default bindings as much as possible. All mentioned
bindings should work out of the box.</em></p>
<p>Applying a single patch is very straightforward: Select the mail in the pager
and hit <code>|</code> to pipe it to an external command. This command will be some
variation of <code>git-am(1)</code>, perhaps <code>git am -s</code> to also add a <code>Signed-off-by</code>
trailer.</p>
<p>What if you want to apply a patch series, however? An obvious solution would be
to pipe each message in the thread to <code>git-am(1)</code>. The <code><pipe-message></code> command
we invoked earlier with <code>|</code> only applies to the currently selected message, so
we can't use that on the whole thread. Instead we can tag the whole thread using
<code><Esc>t</code>, then use the <code><tag-prefix></code> command <code>;</code> followed by <code>|</code> to send all
tagged messages to <code>git-am(1)</code>.</p>
<p>There's two problems with this, though. The first is that depending on the setting
of <a href="https://neomutt.org/guide/reference#3-280-%C2%A0pipe_split"><code>pipe_split</code></a>,
<code>git-am(1)</code> might only apply the first patch in the series. This is the case if
<code>pipe_split</code> is set to the default of <code>no</code>; <code>mutt(1)</code> will then concatenate the
messages before sending them to the external command. Sadly this concatenated
format is slightly different from the <code>mbox</code> format that <code>git-am(1)</code> expects,
making it not see anything past the first patch.</p>
<p>With <code>pipe_split</code> set to <code>yes</code>, <code>mutt(1)</code> spawns one process per tagged mail
instead, applying all patches correctly. Now that <code>git-am(1)</code> is spawned once
per mail, however, you lose its atomicity: Neither <code>ORIG_HEAD</code> will be set
correctly, nor will <code>--abort</code> go back to the original branch.</p>
<p>This might not be a big issue, but I am not a fan. Thankfully <code>git-am(1)</code>
supports reading patches from <code>mbox</code> files or <code>Maildir</code> structures. So instead
of piping mails to <code>git-am(1)</code> via <code><pipe-message></code>, let's save them to the
current directory: With the thread still tagged, <code>;C</code> (<code><tag-prefix></code> followed
by <code><copy-message></code>) will save a copy of it under a given path. Now you can
apply the series by hitting <code>!</code> and running <code>git am -s <path></code>. This works with
<a href="https://neomutt.org/guide/reference#3-188-%C2%A0mbox_type"><code>mbox_type</code></a> set to
either <code>mbox</code> or <code>Maildir</code> (but see <a class="internal" href="/9">№ 9</a>
).</p>
<p>Of course there is no need to rely on the default bindings, especially if you
need to do this kind of thing very often. <code>mutt(1)</code> is easily customizable,
making it possible to bind the entire chain of actions to just one keystroke.
If you're interested in a more detailed examination of a patch-based workflow
with <code>mutt(1)</code>, check out this
<a href="http://kroah.com/log/blog/2019/08/14/patch-workflow-with-mutt-2019/">post</a>
by Greg Kroah-Hartman.</p>
wolfWrap-around search in less(1)2021-07-09T22:28:13+02:002021-07-09T22:28:13+02:00https://zunzuncito.oriole.systems/7/<p>I recently became frightfully aware of how much time I spend in
<a href="https://greenwoodsoftware.com/less/"><code>less(1)</code></a>.</p>
<p>It's never been a utility I gave much conscious thought and I realized that it
is one of those programs that go largely ignored and underappreciated just for
their ubiquity and unobtrusiveness. For most people piping something to
<code>less(1)</code> has most likely become second nature. In the same way it is surely
unthinkable for some to read log files and manuals in anything other than
<code>less(1)</code>, or use any other pager for the Git suite.</p>
<p>If you've not given <code>less(1)</code> a closer look, I invite you to read <a href="https://man7.org/linux/man-pages/man1/less.1.html">its
manual</a>. There's lots of
neat features you might have missed, like filtering lines with <code>&</code>, toggling any
command-line option on the fly with <code>-</code>, following input as it appears with <code>F</code>,
or opening the current file in an editor with <code>v</code>.</p>
<p>A feature I discovered only recently is the "wrap-around search modifier".
Introduced in
<a href="https://github.com/gwsw/less/commit/27e2643875e010c30f9d51eb1124855b707806f4">late 2020</a>
(past version 565), this modifier obsoletes the common dance of <code>g</code> and <code>n</code> to
redo the current search on the whole file. Now, if you hit <code>Ctrl-W</code> right after
issuing a forward or backward search, <code>less(1)</code> toggles search wrap-around.</p>
<p>There is no option to turn this behaviour on automatically. However, it is
possible to override the <code>/</code> and <code>?</code> bindings using
<a href="https://man7.org/linux/man-pages/man1/lesskey.1.html"><code>lesskey(1)</code></a>.
Put the following in <code>~/.lesskey</code>, run <code>lesskey</code>
(<a href="https://github.com/gwsw/less/commit/a2137dcb01cbf46f148828a7389540dd5b51bff1">not needed</a>
on versions past 590), and <code>less(1)</code> should now wrap the search automatically:</p>
<pre><code>#command
/ forw-search ^W
? back-search ^W
</code></pre>
wolfFirefox and the Link HTTP header2021-07-03T13:23:34+02:002021-07-03T13:23:34+02:00https://zunzuncito.oriole.systems/6/<p>HTTP <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link">defines</a>
the <em>Link</em> header with which
<a href="https://www.iana.org/assignments/link-relations/link-relations.xhtml"><em>Link Relations</em></a>
can be defined directly in the HTTP response. This lets websites define their
stylesheets or favicons without having to pass them in an HTML
<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link"><code><link></code></a>
element.</p>
<p>When displaying certain files directly, Firefox wraps them in its own HTML. This
happens, for example, when you look at a <code>.txt</code> file marked as <code>text/plain</code> or
an image marked as <code>image/png</code>.</p>
<p>Turns out that for plain-text files, Firefox will load and honour any stylesheet
passed to it in the <em>Link</em> header and apply it to its own HTML. One could, for
example, link a stylesheet that overrides the font settings, or even include
pictures. Firefox will duly load all of these when displaying the file, whilst
<em>View Page Source</em> will still show only the file itself. It is only when
looking at the HTTP response and the <em>Network</em> tab in the Inspector that you see
what exactly is happening.</p>
<figure>
<a href="/6/firefox-link-header.png">
<img src="https://zunzuncito.oriole.systems/processed_images/21f58dd8c152469300.jpg" alt="Firefox displaying a plain-text file
alongside a picture." />
</a>
<figcaption class="smaller">A plain-text file... in Comic Sans... that also
displays a picture?</figcaption>
</figure>
<p>This does not seem to work when Firefox is displaying images and it doesn't work
<em>at all</em> in Chromium-based browsers. The only relevant entry in Mozilla's
Bugzilla instance I could find was
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=748294">this issue</a>
from 9 years ago.</p>
<p>Arguably this could be considered a bug, and I do strongly feel that Firefox
<strong>should not</strong> load any outside resource when displaying plain-text files. For
now, though, have fun confusing people with this.</p>
<p>Thanks to <a href="https://puck.moe">puck</a> for pointing this out to me.</p>
wolf(Un)Blinking cursors2021-06-17T20:37:37+02:002021-06-17T20:37:37+02:00https://zunzuncito.oriole.systems/4/<p>Whilst reviewing and discussing <a href="https://git.oriole.systems/weltschmerz/commit/?id=0774a46257bdc6daa1c6a1c3485d75bd07ef849c">this
patch</a>
for weltschmerz I found out that there actually exists a global property
<a href="https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-cursor-blink"><code>gtk-cursor-blink</code></a>
that is honoured by all applications that build on GTK.</p>
<p>I don't think I've ever seen this exposed in a settings dialog. Perhaps in the
accessibility settings, I rarely venture there. In any case, you can put
properties like these straight into <code>~/.config/gtk-3.0/settings.ini</code> and GTK
apps will pick them up.</p>
<p>For QT apps it seems you can set
<a href="https://doc.qt.io/qt-5/qapplication.html#cursorFlashTime-prop"><code>cursorFlashTime</code></a>
to a negative value in the aptly named <code>~/.config/Trolltech.conf</code> but I could
not get this to work with the only QT app that I use, quassel.</p>
<p>Not that I would want to, I do prefer a blinking cursor.</p>
wolfPatch workflows and git branch -d2021-06-13T20:22:51+02:002021-06-13T20:22:51+02:00https://zunzuncito.oriole.systems/3/<p>The notion of a "merged" branch is highly dependent on the
<a href="https://git-scm.com/docs/gitworkflows">workflow</a> used for a project. I was
wanting to clean up some topic branches in my copy of git.git today, but <code>git branch -d</code> refused to delete them, pointing out that they were not yet merged.</p>
<p>I knew for a fact that they were, which made me look up how <code>git branch -d</code>
actually determines that. The manual is not entirely clear, but a
<a href="https://github.com/git/git/blob/211eca0895794362184da2be2a2d812d070719d3/builtin/branch.c#L116-L121">comment</a>
in the code pointed out that git constructs the merge base of the branch and its
upstream (or <code>HEAD</code> if there is none) and checks whether the branch is reachable
from that merge base.</p>
<p>In a patch workflow, this will generally not be true. A lot of things may
happen to your patches before inclusion, and with git.git they will get at least
one other sign-off. They'll be recorded in a merge commit, but it will not have
your original branch as one of its parents.</p>
<p>Therefore, neither <code>git branch -d</code> nor <code>git branch --merged</code> will report your
branch as merged. Both of these tools are built for the merge workflow instead.</p>
<p>To see if your work was merged in patch-based workflows, use
<a href="https://git-scm.com/docs/git-cherry"><code>git-cherry(1)</code></a>. Then you can safely
force deletion of the branch with <code>git branch -D</code></p>
wolfDid you mean to go to...2021-06-12T19:47:12+02:002021-06-12T19:47:12+02:00https://zunzuncito.oriole.systems/2/<p>In recent versions of Firefox, single words are looked up via DNS when you enter
them in the URL bar. If the word resolves, the browser "helpfully" indicates
that there's a page at <code>http://<word></code> to visit.</p>
<p>Weird feature, though when taken at face value I can see its usefulness with a
combined search and URL bar. Ideally you'd have completely different semantics
for searching and (direct) browsing, but I don't think something like this is
forthcoming. If anything I'd expect direct browsing to be ever more discouraged.
Nowadays search engines, not browsers, are the gateway to the internet.</p>
<p>In any case, turns out this feature also has <a href="https://bugzilla.mozilla.org/1642623">interesting
side-effects</a> with (browser-based) DoH
turned on. If you ever need to turn it off, Firefox 78 added the following
about:config switch:</p>
<pre><code>browser.urlbar.dnsResolveSingleWordsAfterSearch
</code></pre>
<p>Not that I think this is a great solution. DoH should be done on a system-wide
level (with local queries sent to your router or resolved through mDNS) and
there should be a way of trusting your router's DNS to not forward local queries
to your ISP.</p>