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

Issue 889747 link

Starred by 4 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 12
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Cursor in Crostini VSCode is tiny

Project Member Reported by benwells@chromium.org, Sep 27

Issue description

Chrome Version: 71.0.3558.0
OS: Chrome OS

What steps will reproduce the problem?
(1) Install VS Code
(2) Run it
(3) Notice everything looks good except the cursor is tiny.

This is probably some DPI issue I guess, but it is only the cursor that looks tiny. Everything else looks good to me.
 
@benwells could you share a screenshot? Are you using a non-default scaling factor? And is this the normal mouse cursor, insert caret, or something else?
I couldn't capture the mouse in the screenshot but showed Tom offline.

BTW I installed VS Code via flatpak.
Cc: jopra@google.com raymes@chromium.org reve...@chromium.org
I can repro this with the flatpak VS Code. It appears that they are setting their own cursor icons, which don't get scaled. Is there some way we can force VS Code to use the standard Chrome OS cursors?
Labels: -Pri-3 M-72 Pri-2
Owner: jkardatzke@chromium.org
Status: Assigned (was: Untriaged)
This is interesting...from my first test, this problem occurs in VSCode if you have the flatpak version installed. You do not need to run the flatpak version...it affects the regular version as well if both are installed.

If you then uninstall both of them and reinstall just the .deb file...the problem still occurs..HOWEVER, once you restart the container than the problem goes away (I only had the .deb variant installed at that point).

So I'm going to need to do more digging into this with testing variations to see where exactly this problem is coming from.
Cc: timzheng@chromium.org
Status: Started (was: Assigned)
If you start up a container that just has the .deb version installed it'll run fine. If you then install flatpak and the VSCode flatpak; the .deb version still runs fine at that point. If you then run the flatpak version you have a tiny cursor.

And now I'm unable to reproduce having a tiny cursor with the .deb variant....boo.

I don't think this is flatpak related actually...because I have a secondary container I created for this which I have only installed the .deb file into and all of a sudden that one is having problems as well.

I have a hunch this is related to the recent changes we did to handle UI scaling.  If I launch VSCode from the terminal and set the DISPLAY and WAYLAND_DISPLAY vars...then I can get it to use the wrong size cursor (and if I then set it to scale up, it'll have the right sized cursor...although it will be blurry).

I'll do more analysis tomorrow as now I fear this may affect more apps.
This is actually a flatpak bug that's apparently been fixed since:

https://github.com/flathub/org.libreoffice.LibreOffice/issues/32

And this fix is in version 18.08 of the freedesktop SDK that is being used in my test...so this is probably a configuration issue on our end at this point.
Found a hacky workaround...if you run this from the terminal:

flatpak run --command=sh com.visualstudio.code
export XCURSOR_THEME=Adwaita
code

Then it'll render with the proper sized cursors...apparently it's not figuring out which cursor theme to use properly inside of the flatpak sandbox for some reason.
OK...easier workaround which we should be able to actually implement to fix this:

export XCURSOR_THEME=Adwaita
flatpak run --command=sh com.visualstudio.code
Nevermind #9...that doesn't work...the earlier export into the sandbox remained from a prior test.
This is just totally inconsistent. Setting XCURSOR_THEME fixes this temporarily...but then it won't work again after I restart the container.

Sanity slightly returning now...apparently XCURSOR_THEME is needed to fix this....HOWEVER...when I'm seeing that be set but it doesn't work, for some reason XCURSOR_SIZE is set to 24 instead of 48 on those test runs.  Trying to figure out why that is now.
XCURSOR_SIZE issue is due to another recent change where we run 2 instances of sommelier to support scaling of apps.  Sommelier exports the XCURSOR_SIZE env var from itself...and now it's a race for which one does it last to determine whether it is 48 (correct) or 24 (incorrect)...at least on a Pixelbook.  I will open another bug for that issue since it is separate from this one...and that issue affects even more apps (such as emacs).
Project Member

Comment 13 by bugdroid1@chromium.org, Oct 12

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/containers/cros-container-guest-tools/+/d983807780122da84f417dd19ae270025e3801bb

commit d983807780122da84f417dd19ae270025e3801bb
Author: Jeffrey Kardatzke <jkardatzke@google.com>
Date: Fri Oct 12 00:33:54 2018

cros-garcon: Set XCURSOR_THEME for flatpak apps

This fixes a bug where flatpak apps would have tiny cursors because they
weren't using the cursor theme. Flatpak is supposed to default to the
Adwaita theme...but is not using it for the cursor for some reason.
Setting this in the environment fixes the problem.

Note that this fix will not always work until  crbug.com/894276  is also
fixed.

BUG= chromium:889747 
TEST=Manually verified on eve

Change-Id: I4a77ef76f76a59507cd2ad00b21e7f2b09f52663
Reviewed-on: https://chromium-review.googlesource.com/1275085
Commit-Ready: Jeffrey Kardatzke <jkardatzke@google.com>
Tested-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: Jeffrey Kardatzke <jkardatzke@google.com>
Reviewed-by: David Reveman <reveman@chromium.org>

[modify] https://crrev.com/d983807780122da84f417dd19ae270025e3801bb/cros-garcon/BUILD
[modify] https://crrev.com/d983807780122da84f417dd19ae270025e3801bb/cros-garcon/cros-garcon-override.conf

Status: Fixed (was: Started)

Sign in to add a comment