[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


Hi,

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!

Cheers,
Toby.
-- 
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