Seems old  issue 458065  is coming back.

atwilson@, could you triage and find an owner? Thanks.

We have a customer facing this issue, case #14488176.
Here is the video reproduction of the issue: https://drive.google.com/open?id=1Xh1oMWFYZgjkrc6zSn3prej5aD2G_PpJ
Drive link to debug logs: https://drive.google.com/open?id=1zmVd1un_yBgD6mgrJssYf4ipz-JNvR0L 
Chrome OS version: 63.0.3239.116 
Devices affected:aOpen ChromeBox devices; aOpen Chromebase Mini

We are seeing this with ASUS CS10 Chromebits too. Can mitigate by restarting chrome it after powering up screen but we schedule power on screens and there is no way to set Chromebit to power cycle at a specific time unless you use a third party signage solution like Appspace 

Confirming another customer is experiencing this issue with Adobe's AEM Signage App running in single-app kiosk mode.

The device affected include the AOPEN Chromebox Commercial and AOPEN Chromebox Mini.

Customer is claiming that physically connecting a mouse to move the cursor to the corner is a temporary fix.  The mouse cursor will re-appear in the center after rebooting.

[Raising priority as more customers seem to be reporting this]

As per above same issue.

Another customer is experiencing this issue with Adobe's AEM Signage App running in single-app kiosk mode.

The device affected AOPEN Chromebox Mini.

Suggested Customer to physically connecting a mouse to move the cursor to the corner as temporary fix. This worked.

I reproduced it. Looks like the mouse appears only if screen rotation is configured and 'DisplayRotationDefault' policy is set to 90, 180 or 270 degrees.

We are experiencing the issue but do not have screen rotation configured. At least you were able to reproduce it though!

More investigation results:
When screen is rotated, WindowTreeHostManager::UpdateMouseLocationAfterDisplayChange() is called which requests to move the cursor to some position (https://cs.chromium.org/chromium/src/ash/display/window_tree_host_manager.cc?l=472&rcl=c893771d021422d7110221721beda4d79ecacd3b) that after a long chain is calls ends up in CompoundEventFilter::SetCursorVisibilityOnEvent() that just shows the cursor here: https://cs.chromium.org/chromium/src/ui/wm/core/compound_event_filter.cc?l=152&rcl=7af24b97fe4f69e15aa03ea2334be167355257c4

I'll re-assign to Mitsuru to triage and investigate in Chrome OS UI team.

The 10 screens I am seeing this on are also mounted in portrait mode so have a 90 degree rotation set. I dont believe I have seen it on any of the landscape screens.

We have seen this using the default and out of the box settings without anything related to portrait or landscape or rotation configured. We use the AOpen Chromebox Commercial and mini.

Oshima, this is the mouse cursor issue we discussed. Any ideas here?

Just started look into.

I have a CL and now working on fixing tests. I should be able to land it early next week.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ccfa74c42fb68d038a6a995278eff53f287fcc3e

commit ccfa74c42fb68d038a6a995278eff53f287fcc3e
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Thu Feb 01 17:43:24 2018

Do not move the cursor if the cursor is invisible

Do not move the cursor if the cursor is invisible
when display configuration is changed. This was to
make sure that X11's cursor stays inside a display, as
reconfiguring display can potentially move the cursor
to outside of displays.

I think this is no longer a concern, and I'll
replace this with just a notification after merged to 65.

This also fixes the test harness that assumes the cursor
is visible by default but wasn't.

BUG= 773479 
TEST=covered by unit test. also tested on device.

Change-Id: I7debc957145318352f7ee3c858031091eb2a8e56
Reviewed-on: https://chromium-review.googlesource.com/890056
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533720}
[modify] https://crrev.com/ccfa74c42fb68d038a6a995278eff53f287fcc3e/ash/display/window_tree_host_manager.cc
[modify] https://crrev.com/ccfa74c42fb68d038a6a995278eff53f287fcc3e/ash/display/window_tree_host_manager_unittest.cc
[modify] https://crrev.com/ccfa74c42fb68d038a6a995278eff53f287fcc3e/ash/test/ash_test_helper.cc

Your change meets the bar and is auto-approved for M65. Please go ahead and merge the CL to branch 3325 manually. Please contact milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9735248387107cdaaa2f78aa12b30b21acb86dbd

commit 9735248387107cdaaa2f78aa12b30b21acb86dbd
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Fri Feb 02 18:58:42 2018

Do not move the cursor if the cursor is invisible

Do not move the cursor if the cursor is invisible
when display configuration is changed. This was to
make sure that X11's cursor stays inside a display, as
reconfiguring display can potentially move the cursor
to outside of displays.

I think this is no longer a concern, and I'll
replace this with just a notification after merged to 65.

This also fixes the test harness that assumes the cursor
is visible by default but wasn't.

BUG= 773479 
TEST=covered by unit test. also tested on device.

Change-Id: I7debc957145318352f7ee3c858031091eb2a8e56
Reviewed-on: https://chromium-review.googlesource.com/890056
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Ahmed Fakhry <afakhry@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#533720}(cherry picked from commit ccfa74c42fb68d038a6a995278eff53f287fcc3e)
Reviewed-on: https://chromium-review.googlesource.com/899647
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#261}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/9735248387107cdaaa2f78aa12b30b21acb86dbd/ash/display/window_tree_host_manager.cc
[modify] https://crrev.com/9735248387107cdaaa2f78aa12b30b21acb86dbd/ash/display/window_tree_host_manager_unittest.cc
[modify] https://crrev.com/9735248387107cdaaa2f78aa12b30b21acb86dbd/ash/test/ash_test_helper.cc

 Issue 808501  has been merged into this issue.

I was unable to reproduce the issue that the customer is experiencing. 
Tested on Chrome OS 10176.68.0, 64.0.3282.144 

This Cursor issue also appears with Smart Content Kiosk Player app - cursor appears deadcenter of screen after reboot - mouse cursor can only be hidden if keyboard is connected and the 'esc' key is hit or the mouse cursor is physically moved off screen...

Please provide a fix for this

tldr: will this be fixed in v65 or v66?

Question: Reading through these posts, can I infer that the chromium team is working on a fix for either Chrome v65 or v66?

Still here in v64: I am still having this issue (cursor showing on screen in Kiosk Player App) as of today - my machine is running v.64.0.3282.144


thanks in advance
Jeremy

Fix for the issue should've been landed in M65 and later. It could be still present on M64.

Customer confirming mouse cursor still present in latest stable channel release:  64.0.3282.167	

Suggested workaround by moving to M65 (currently beta)?

@35 -

I just checked Google's Admin Console - it's how we manage our devices. I would assume many of the other commentors on this post do the same.

The console does not allow to update to M65 yet.

Here is a screenshot of the page.

As you can see - there are options for (i) Channel and (ii) Version

Release Channel: (a) Stable (b) Beta (c) Development

Restrict Google Chrome version to at most: 61, 62, 63, 64



- Any other suggestions you have? (Obviously plugging in a mouse and 'wiggling' cursor removes it - but I can't do that every day for all machines)

- Do you know when M65 will be released?



Thanks for the feedback so far. You guys are awesome!

Deleted: Screenshot 2018-03-08 at 9.08.08 AM.png 41.6 KB

	Screenshot 2018-03-08 at 9.08.08 AM.png 41.6 KB View Download

Customer has confirmed that the latest 65.0.3325.107 (currently Beta) resolves the mouse cursor issue in kiosk mode.

I can confirm that Smart Content app does not show cursor on BETA version 65 - please update this to stable channel.

Thank you