On Tue, 21 Sep 2021 18:47:25 -0700 Marc MERLIN <marc_...@merlins.org> said:
Input goes directly from xserver to chrome - e doesn't handle kbd/mouse input -
at most it positions windows themselves, shows, hides, resizes etc. and the
compositor draws the output of the window content (just one big image for the
window) for where they are.
i have used wm decorations with chrome for years and years and it works just
fine.
so here are the possible options:
1. when e sends the synthetic configurenotifies to chrome it sends the wrong
x/y offset and chrome is somehow not using normal input events but
root-relative coordinates and doing its own offsetting based on this position
and because e sends the wrong position, chrome gets this wrong. if this were
the case it wouldn't be 16 pixels off but more like 23/24 pixels off as that's
the titlebar size. now a good way to test if e is getting this synthetic
configurenotify wrong is with xev. it prints all events a client sees. e wont
differentiate chrome from xev or xterm - they are all windows with borders as
far as e is concerned. so e.g.:
ConfigureNotify event, serial 32, synthetic YES, window 0x3a00001,
event 0x3a00001, window 0x3a00001, (402,23), width 178, height 178,
border_width 0, above 0x0, override NO
so that was xev getting a synthetic configurenotify to say its top-left corner
is at 402 pixels along and 23 pixels down from the top of the screen - i.e. the
titlebar size. so that is correct. there is no other synthetic configurenotify
there. so as best i see e is sending the right info.
2. some new feature in chrome is trying to use raw xinput events with
screen-relative (or well root-relative coords) and needs to do the above offset
based on where it thinks the window is (i.e. this configurenotify event above)
and is .. getting it wrong. when you turn off the built-in borders it doesn't
properly account for that and gets it wrong internally. as the person who did it
probably didn't test with wm borders and devs probably like having chrome
titlebars with their tabs... it probably was missed.
> And that only happens a few seconds after the window is started. The
> first few seconds, click go to the right place.
> After it's broken, if I restart E, clicks go to the right place again
> for a short time (seconds) and then go to the wrong place (16 pixels
> below or somesuch).
>
> If I make the window borderless and let chrome manage borders, then
> clicks go to the correct place again.
> I have filed details in
> https://bugs.chromium.org/p/chromium/issues/detail?id=1251382
>
> If I go back to chrome M93 or any older version, things work great with E.
> Also chrome M95 95.0.4638.10 does fix the border problem with other
> window managers (at least xfce4 that I tested with).
>
> So yes, I still have enlightenment 0.23.1-5, I know there is a newer
> version, but last I checked, it breaks "xkbcomp ~/xkb-keymap :0"
> which I very much rely on for foreign accents, so upgrading is
> problematic.
>
> That said, everything has worked fine for quite a while (year+) until
> that chrome M94 upgrade.
>
> I'm not sure who is to blame, is chrome M95 using something new that is
> incompatible with E 0.23.1 and causing those clicks to be aimed at the
> wrong height after a few seconds?
>
> Thanks,
> Marc
> --
> "A mouse is a device used to point at the xterm you want to type in" - A.S.R.
>
> Home page: http://marc.merlins.org/ | PGP
> 7F55D5F27AAF9D08
>
>
> _______________________________________________
> enlightenment-users mailing list
> enlightenment-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-users
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - ras...@rasterman.com
_______________________________________________
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
