Does not get a window title for Google Chrome #56

Open
stigkj opened this Issue Feb 3, 2013 · 8 comments

Comments

Projects
None yet
8 participants

stigkj commented Feb 3, 2013

Google Chrome does not have a window title like Safari, so selfspy cannot get the title of the currently visited site.

Would it be possible to use the active tab's title? Maybe one needs some way of plugging in code for specific apps?

It could be done by this scripting bridge code, but it is slow:

from Foundation import *
from ScriptingBridge import *

chrome = SBApplication.applicationWithBundleIdentifier_("com.google.Chrome")
print chrome.windows()[0].activeTab().title()

rdslw commented Jul 14, 2014

Bumping it up.
Google Chrome titles are not being reported :(

+1 I have the same issue, and would really like to see the titles being included.

It could be done by this scripting bridge code, but it is slow:

How slow is slow? Is it tolerable?

@dspeckhard dspeckhard added a commit to dspeckhard/selfspy that referenced this issue May 7, 2015

@dspeckhard dspeckhard Fix for Issue #56, Google Chrome Window Titles 5ca473a

I opened a Pull Request that used the Scripting Bridge code above. In my limited testing, no noticeable CPU use / load variance (not perceptible, at least).
#125

buma commented May 23, 2015

Selfspy can't get name of Chrome since selfspy uses python-xlib which supports only Strings as Window names.

Chrome since one version reports name as UTF8_STRING and since only STRING is requested and isn't found Xlib returns empty string and Selfspy is none the wiser.

Fix for this can be to change Xlib to request any type. And if returned type is UTF8_STRING decode it to unicode and then in selfspy don't decode it with latin1 (since you can't encode all utf8 characters in utf-8 string). Title column in selfspy database is Unicode anyway.

But then you have a problem with Firefox which returns String for WM_NAME if title has only ascii characters or COMPOUND_STRING if it doesn't. COMPOUND_STRING encoding is strange.

But not all is bad. Both FF and Chrome supports newer _NET_WM_NAME property which is always in UTF8_STRING. This property is part of XDG/EWMH specifications. So we can try to first get this property and if this fails old one.

EDIT: to test what program uses use xprop | grep WM_NAME and click on a window

@buma buma added a commit to buma/selfspy that referenced this issue May 24, 2015

@buma buma Added support for Unicode wm_name
This also needs support from python-xlib
Fixes #56
1532704

buma commented May 24, 2015

I added patch file with needed changes for python-xlib on gist.

It seems that _NET_WM_NAME isn't supported in Xlib so change to xcb would be needed.

@blueyed blueyed added a commit to blueyed/selfspy that referenced this issue Jul 8, 2015

@blueyed blueyed sniff_x: fix getting utf8 window titles, via _NET_WM_NAME
This queried `_NET_WM_NAME` first, before falling back to the
python-xlib method, which only queries for `WM_NAME` with type `STRING`
(ignoring `UTF8_STRING` and `COMPOUND_TEXT`) therein.

Ref: gurgeh#56 (comment)
(although #56 itself does not appear to be about the X sniffer).
aa76881
Contributor

blueyed commented Jul 8, 2015

@buma
See #126 for a fix for the X sniffer - not really relevant to this issue, although the outcome seems to be the same.

nalt commented Dec 2, 2015

So, what is the preferred way to fix this on MacOS? #125 does work, but it is an application-specific fix.

klloe commented Jan 4, 2017

I've the samme issue but with firefox.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment