New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 889953 link

Starred by 1 user
Status: Assigned
Owner:
mukai@chromium.org
Cc:
█ alexst@chromium.org
rjkroege@chromium.org
dcasta...@chromium.org
█ reve...@chromium.org
tbuck...@chromium.org
spang@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

gtk app can't receive keyevents when running on chrome for chromeos +glinux

Project Member Reported by osh...@chromium.org, Sep 27 
This works fine on device, so not high prioirty but it's very inconvenent when testing. mukai-san, can you take a look?

Comment 1 by mukai@chromium.org, Sep 27 

It seems USE_XKBCOMMON buildflag is not set when building chrome-for-chromeos on Linux -- this means keyboard capability is not set (https://cs.chromium.org/chromium/src/components/exo/wayland/server.cc?q=components/exo/wayland/server.cc&sq=package:chromium&g=0&l=4133) so the gtk3 apps will think there are no keyboards. Also lots of keyboard features (like keymaps) are not properly processed.

Confirmed that rebuilding Chrome with 'use_xkbcommon=true' GN arg fixes the problem.

I'm not sure the actual reason why it gets broken recently -- it has been false by default for years (https://chromium.googlesource.com/chromium/src/+blame/591149a84c42e88b0fd87dd91070351425ca1bd6/ui/base/ui_features.gni)

Comment 2 by osh...@chromium.org, Sep 28

Cc: rjkroege@chromium.org alexst@chromium.org spang@chromium.org
Adding ozone folks.

Is there a reason why this is false by default on chromeos?
►

Sign in to add a comment