Chrome has blank title for active page

[nomeata]

Original report by Anonymous.

---

I've been using arbtt on Mac OS for the better part of a week. A lot of my workday is spent in Chrome because I have several Google accounts that I switch between for various projects. In arbtt-dump, I always see two Chrome windows - one with a blank title and one with the actual active page I was looking at. When this sample was taken, I had the Dashboard tab open on my desktop, but the blank page is displayed.

2019-01-10 21:04:16 (353ms inactive):
    (*) Google Chrome:
    ( ) Google Chrome:  Dashboard
    ( ) Atom:           categorize.cfg — ~/.arbtt
    ( ) iTerm2:         1. fish  /Users/bbennett/Desktop/dev/arbtt-graph (fish)
    ( ) Finder:         arbtt-graph
    ( ) Notes:          Notes

Chrome is the only program this happens in. Are there other Mac users seeing the same thing? Because Chrome logs empty titles as active, I lose out on a lot of information about what I'm working on in the browser.

[VitamintK]

I'm experiencing this too (Mac OS 11.4, Big Sur) but only sometimes! It works correctly 3/4 of the time, and exhibits the above behavior (Google Chrome: ) 1/4 of the time. Haven't figured out what causes it yet.

[VitamintK]

Oh wow ok, this is crazy but I reproed one case where a titleless Chrome Window will be the active window instead of the actual title of the page:

When hovering over a link and Chrome has this link URL preview thing in the lower-left:

The active window will be a fake title-less Chrome "window", and the real titled window will show in arbtt as inactive.

[VitamintK]

Another case: When using cmd+F, the "find in page" UI element will also cause a fake, untitled window to be considered active instead of the actual page (regardless of whether the UI element has focus or not).

[nomeata]

I wonder if there is some xprop on the window that says that it’s actually a subwindow of another one?

[VitamintK]

Not sure. I couldn't find anything like that. I tried doing some analysis (cribbed from this stackexchange answer) looking at the attributes of each window:

> python2
Python 2.7.16 (default, May  8 2021, 11:48:02)
>>> from Quartz import CGWindowListCreate as create_list
>>> from Quartz import CGMainDisplayID as display_id
>>> from Quartz import CGWindowListCreateDescriptionFromArray as lookup
>>>lookup(create_list(display_id(), 0))
....
....
....
{
        kCGWindowAlpha = 1;
        kCGWindowBounds =         {
            Height = 62;
            Width = 367;
            X = 1100;
            Y = 94;
        };
        kCGWindowIsOnscreen = 1;
        kCGWindowLayer = 0;
        kCGWindowMemoryUsage = 1232;
        kCGWindowName = "";
        kCGWindowNumber = 216456;
        kCGWindowOwnerName = "Google Chrome";
        kCGWindowOwnerPID = 52249;
        kCGWindowSharingState = 1;
        kCGWindowStoreType = 1;
    },
....
....

none of which signal any parent-child relationship, and the value for kCGWindowOwnerPID is the same as it is for the actual, correct Chrome window.

I'm going to try hard-coding a rule in Window.hs so that a nameless Chrome window won't be considered foreground windows. This will be totally satisfactory for my own purposes, but I'm not sure if it should be merged into master here, since it's very hacky.

[nomeata]

You could also try to work around it in your rules, similar to how I try to assign tags based on the folder opened in my mail client, even when I am editing an email:

-- I'd like to know what evolution folders I'm working in. But when sending a
-- mail, the window title only contains the (not very helpful) subject. So I do
-- not tag necessarily by the active window title, but the title that contains
-- the folder
current window $program == "evolution" &&
any window ($program == "evolution" && $title =~ /^(.*) \([0-9]+/)
  ==> tag Evo-Folder:$1,

[VitamintK]

ah yeah, that would be a decent workaround too, but it would get pretty verbose as I have many, many Chrome-based rules, and I'd have to add that little bit of logic to each Chrome-based rule, right?

Here's the hacky fix I implemented, which seems to have solved the issue for me: https://github.com/VitamintK/arbtt/commit/93a19b1aef552f4c48e93acf83408d61c12d1061

https://github.com/nomeata/arbtt/compare/master...VitamintK:titleless-chrome-hackfix

[nomeata]

You can maybe have one rule that sets a “chrome active” tag and then later match on that one?