[qutebrowser] Given the process ID, can I find out the loaded URL?

Tobias Dussa tobias-qutebrowser at dussa.de
Wed Dec 30 23:59:24 CET 2020


On Wed, Dec 30, 2020 at 09:40:32PM +0100, Florian Bruhin wrote:
> Your mail was held back because you're not subscribed to the
> mailinglist. I've now approved it and added you to the allowed senders,
> but you might not get replies if people don't add you to Cc.

ACK.  THX for the pointer.  I thought I explicitly read somewhere that
subscribing to the list was optional, so I figured I'd be included in the
thread I started automagically.  Subscribed now.

> > I have come across this question: If I know the process ID of a QB thread,
> > is it possible to figure out (from the command line) what URL is currently
> > loaded in the corresponding tab?
> > Haven't been able to find an answer to this question.  I suspect it should
> > be possible if I dig in the right place in /proc/${PID}, but.
> Quoting from an earlier reply to (almost) the same question:
> https://lists.schokokeks.org/pipermail/qutebrowser/2020-October/000815.html

Indeed, that reads like exactly my problem.

> I added the API to do those kind of things upstream in Qt 5.15:
> https://codereview.qt-project.org/c/qt/qtwebengine/+/286981
> However, I didn't get around to actually implementing something to e.g.
> show the PID inside qutebrowser - currently tracked here:
> https://github.com/qutebrowser/qutebrowser/issues/4984

I'm not actually sure whether that really tackles the right problem.  It
kinda sounds like it solves the _inverse_ problem, getting a PID for a
given tab.

> Right now, the easiest thing you can do is to send a SIGSTP to the
> process and see which tab is frozen; or send a SIGTERM and see which tab
> crashes.

Well... :) This ceases to be feasible when you have sufficiently many
tabs/processes open... ;-)

In my particular case, I was trying to hunt down what web site suddenly
started producing audio output.  I got the PID via pacmd, but then what?
Obviously, I could shoot down the process to make the audio output stop,
but that was not the intention. ;-)
Indeed, I had not thought of just sending a SIGSTOP instead, but it'd
still be tedious to find the right tab.  It'd be much easier if the
currently loaded URL could be queried somehow via CLI.  (But, of course, I
realize this is a somewhat exotic request. :))

> Also, @toofar wrote a slightly crazy script to find the offending tab
> automatically:
> https://gist.github.com/toofar/33cd9baf420f327472f7eb7d7b2e3f6a

This sounds interesting.  THX for the pointer!

Usenet est omnis divisa in partes tres, quarum unam incolunt Trolli,
aliam useri regulari, tertiam, qui ipsorum lingua administratores,
nostra summi dei appellantur.

More information about the qutebrowser mailing list