Thanks for the feedback from everyone. We are looking actively into this. The biggest help we can get is getting steps to reproduce this.

Alternatively, the moment this happens with you, please file a feedback report (alt-shift-i) perhaps we can glean something from the logs. Let us know time and email address of who filed the report so we can retrieve it from the backend.


+Stephane

@everyone affected. We need help bisecting this as we still cannot reproduce on our side. I will pull down images of various versions you can test. Please post here the devices which you could test on:

http://goo.gl/forms/QtMQKO4RTxrEdkD92


I will then provide test images which can help us track down the issue (absent any repro steps).

To Stephane

I have done as instructed and sent a Feedback report as I lost the mouse pointer in a PowerShell session using a ChromeBox entering Citrix. I got the mouse pointer back by put on Large Mouse Cursor in the Chrome Accessibilty options, but this is not really a satisfactory workaround. There needs to be a fix applied to this as we have a few hundred Chrome users who depend on enter Citrix Applications to do their day jobs. This could be scoped to go up to a few thousand Chrome users in the future, but if this problems is not resolved soon, we may have to think about flicking them back to Windows.

Many thanks

Added images to this folder and everyone on this bug has access permissions.

I started with three beta builds, the first (should not have the issue), the last (should have the issue), and the one in the middle for Pixel 1 and Asus CN62 (will add more as folks answer the form).

Please update us on the results of testing so we can better zoom in on the bug and revert the offending change immediately.


https://drive.google.com/a/google.com/folderview?id=0B7nGgEn7uQ4ubmxwMHJsT3ROMlU

Hi

I tried to run one of the bin files and I got an error message (see screen-print) saying the file type is not supported. I have to admit I am not a Chrome OS specialist, how can I run these file to update the Chrome OS?

Many thanks

Sorry added the wrong attachment so will add this one. How do you run this update?

Deleted: Screenshot 2016-07-06 at 12.33.37.png 141 KB

	Screenshot 2016-07-06 at 12.33.37.png 141 KB View Download

I think you should use this utility from the Chrome webstore : https://chrome.google.com/webstore/detail/chromebook-recovery-utili/jndclpdbaamdhonoechobihbbiimdgai/ and point it to the downloaded .bin file

You need to burn these images on a USB disk and use that to boot Chrome OS. You have to write those images from a different computer than the Chromebook. Instructions on how to burn are here. Ignore step #1 as the images I provided are already unzipped  -  http://arnoldthebat.co.uk/wordpress/chromium-os/


Once the image is burned, the Chromebook has to be recovered with this image

1. Enter recovery mode:
       If you have a Chromebook with a keyboard, press and hold Esc + Refresh + Power. Let go of Power, then let go of the other keys.
       If you have a Chromebox or Chromebit, turn it off, press its recovery button, then press the Power button to turn it back on. To find the location of the recovery button, see the user manual.

2. You'll see one of these messages:
       "Chrome OS is missing or damaged. Please insert a recovery USB stick or SD card."
       "Please insert a recovery USB stick or SD card."

3. Insert the recovery media you've created (SD card or USB drive).

4. Follow the on-screen instructions.



Not sure using the utility mentioned will help as that will point you to the latest image (not the older ones we are trying to test). I wasn't aware it can point to a local file?

I will test the builds on a pixel 1 and asus chromebox on friday Aust time. 

Added HP Chromebox and Asus CN60 to the images folder. Images in folder now

Pixel 1
Asus CN60
Asus CN62
HP Chromebox



Images covering first beta release, last beta release, and the release in the middle.

Hi,

Thank you very much for helping out testing.
I've been testing multiple versions in 51 Beta, and the first version I can reproduce this issue is 51.0.2692.0
Please let me know if you have seen this earlier than 51.0.2692.0
Since this issue is intermittent, git bisect might not be very reliable. I'm still trying to find the root cause. In the meantime, it will be helpful to know which version first introduced this regression.

Hi,

we have noticed this issue on Chrome OS ver51.0.2704.79 (64-bit). We also tried the latest update (ver51.0.2704.103) but it still has the issue.

So far we have rolled back our ChromeOS to ver49.0 where the mouse issue is not occuring.

@xiaoyinh, version 51.0.2692.0 was while it was still in Dev channel. First beta was 51.0.2704.29.

If you can confirm this? It sounds like it's introduce pre-beta and some earlier images are needed. I can provided if needed.

gbirtchnell@, I have reproduced the issue twice in 51.0.2692.0 based on different commits. 
I think it might worth testing earlier images to see which version it is exactly introduced.

Updated the images in the folder to 51.0.2688.0 which is the first dev build in M51. Can anyone reproduce the issues on that image?

This morning we tried to reproduce this on ToT, but not managed to get a repro.
I have some log messages last time I ran into this issue. 

And it seems like every time we move the cursor in virtual session it triggers EventHandler::handleMouseMoveOrLeaveEvent and it calls 
EventHandler::selectCursor to pick an appropriate cursor. 
For the custom cursor, it uses cachedImage to create the cursor.

From the log messages, when the issue happens, it is getting an empty image from cachedImage and using it to create the cursor.(https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/input/EventHandler.cpp?rcl=1467904650&l=652, image here is null). 
Then it pass down to FrameView::setCursor and then WebCursor::InitFromCursorInfo.

I'm not quite sure why the image it is geting is null.
rbyers@, thakis@, If you have some insight on this?
 
 
I'm now trying to repro this with a older build to confirm my assumption.


See the log message as follows:

Good case:
1:1:0628/101648:ERROR:EventHandler.cpp(611)] OptionalCursor EventHandler::selectCursor
[1:1:0628/101648:ERROR:EventHandler.cpp(640)] case SetCursorBasedOnStyle:
[1:1:0628/101648:ERROR:EventHandler.cpp(652)] if style && style->cursors()
[1:1:0628/101648:ERROR:EventHandler.cpp(682)] image.size.width=64, image.size.height=64
[1:1:0628/101648:ERROR:EventHandler.cpp(683)] Create Cursor: Cursor(image, hotSpotSpecified, hotSpot, scale);
[1:1:0628/101648:ERROR:FrameView.cpp(3129)] FrameView::setCursor
[1:1:0628/101648:ERROR:ChromeClientImpl.cpp(734)] ChromeClientImpl::setCursor(const Cursor& cursor, LocalFrame* localRoot)
[1:1:0628/101648:ERROR:ChromeClientImpl.cpp(742)] ChromeClientImpl::setCursor
[1:1:0628/101648:ERROR:ChromeClientImpl.cpp(761)] m_webView->client()->didChangeCursor(cursor)
[1:1:0628/101648:ERROR:render_view_impl.cc(2019)] RenderViewImpl::didChangeCursor
[1:1:0628/101648:ERROR:render_widget.cc(1211)] RenderWidget::didChangeCursor
[1:1:0628/101648:ERROR:cursor_utils.cc(33)] InitializeCursorFromWebCursorInfo
[1:1:0628/101648:ERROR:webcursor.cc(43)] WebCursor::InitFromCursorInfo
[1:1:0628/101648:ERROR:webcursor.cc(49)] This is Custom cursor
[1:1:0628/101648:ERROR:webcursor.cc(190)] custom_data not empty.



Bad case:
OptionalCursor EventHandler::selectCursor
[1:1:0628/101649:ERROR:EventHandler.cpp(640)] case SetCursorBasedOnStyle:
[1:1:0628/101649:ERROR:EventHandler.cpp(652)] if style && style->cursors()
[1:1:0628/101649:ERROR:EventHandler.cpp(680)] Image is null
[1:1:0628/101649:ERROR:EventHandler.cpp(682)] image.size.width=0, image.size.height=0
[1:1:0628/101649:ERROR:EventHandler.cpp(683)] Create Cursor: Cursor(image, hotSpotSpecified, hotSpot, scale);
[1:1:0628/101649:ERROR:EventHandler.cpp(602)] setcursor here
[1:1:0628/101649:ERROR:FrameView.cpp(3129)] FrameView::setCursor
[1:1:0628/101649:ERROR:ChromeClientImpl.cpp(734)] ChromeClientImpl::setCursor(const Cursor& cursor, LocalFrame* localRoot)
[1:1:0628/101649:ERROR:ChromeClientImpl.cpp(742)] ChromeClientImpl::setCursor
[1:1:0628/101649:ERROR:ChromeClientImpl.cpp(744)] custom_image of cursor is empty
[1:1:0628/101649:ERROR:ChromeClientImpl.cpp(761)] m_webView->client()->didChangeCursor(cursor)
[1:1:0628/101649:ERROR:render_view_impl.cc(2019)] RenderViewImpl::didChangeCursor
[1:1:0628/101649:ERROR:render_widget.cc(1211)] RenderWidget::didChangeCursor
[1:1:0628/101649:ERROR:cursor_utils.cc(33)] InitializeCursorFromWebCursorInfo
[1:1:0628/101649:ERROR:cursor_utils.cc(39)] custom_image of web_cursor_info is empty
[1:1:0628/101649:ERROR:webcursor.cc(43)] WebCursor::InitFromCursorInfo
[1:1:0628/101649:ERROR:webcursor.cc(43)] This is Custom cursor
 

Can not reproduce the issue on 51.0.2688.0 Dev on the Asus CN62 chromebox

Thanks srcrew@.

Please find a new Dev build from 7 days later for Asus CN62 : 51.0.2699.0
https://drive.google.com/corp/drive/u/0/folders/0B7nGgEn7uQ4ubjF5cEE5dVQwSkE 

Version 51.0.2699.0 available for following devices:

Pixel 1
Asus CN60
Asus CN62
HP Chromebox

https://drive.google.com/a/google.com/folderview?id=0B7nGgEn7uQ4ubmxwMHJsT3ROMlU

Can confirm v51.0.2699.0 has the issue. Although took awhile to happen and started only on dialog boxes first (Like I saw originally). After an hour or so, it will progress to be the whole screen in the citrix interface. 

Here's the change log between 51.0.2688.0 and 51.0.2699.0:

https://chromium.googlesource.com/chromium/src/+log/51.0.2688.0..51.0.2699.0?pretty=fuller&n=10000

Shows a few cursor related commits that may be relevant there:

https://chromium.googlesource.com/chromium/src/+/6071fe20d749ff6ebde0da65c5e3f6fd83065cb9
https://chromium.googlesource.com/chromium/src/+/77570cbc7acd24938eb6da1bed0d9884f31dcec1
https://chromium.googlesource.com/chromium/src/+/5caf6fd59d6f35157a3e6ba4728434ac3d1b0886

Looking at the range and the mouse cursor related CLs, none seems to be suspicious. Adding the authors of those CLs to consult their opinions.

+oshima for: https://codereview.chromium.org/1823913002
+avallee for: https://codereview.chromium.org/1845083002
+haraken for: https://codereview.chromium.org/1853603002 and https://codereview.chromium.org/1852663002

How can I test this bug? It looks like my CL is the most likely culprit as the Chrome APP does use a <webview>.

Could you also provide the full output of chrome://version (copy-paste, not a picture please) including the command line and variations after seeing the bug?

Re #61: I have just sent you over IM details on how you might test this. Thanks for looking into it!

So I've messed around in a couple sessions and I can't see to repro.

I've tried on both a link and peach_pit devices.

I'm going to let the session run for an hour or see and see if the problem happens for me.

Looking at the implementation though shows that the window is a pnacl module drawing the screen with a 100%x100% div above it with the cursor set to some data:png url and some nacl somewhere. The only webview I see is in the login and selection screen so I'm inclined to believe my patch was not responsible for this regression.

Re #63: I don't think your CL is to blame either. I think the problem originates somewhere on the renderer side. Something happens somewhere in blink that we end up getting a nullImage [1] with a zero size.

[1]: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/fetch/ImageResource.cpp?q=ImageResource::getImage&sq=package:chromium&l=269

I have reproduced it in 51.0.2696.0 today. 
According to the log message, in the EventHandler::selectCursor, cursorlist contains a list of cursor info and it is looping through to find a good one. However either in the good or bad case, the cursorlist only have one entry so It feels like cursorlist should be updated everytime the cursor moves, but somehow the image is not or not yet populated when we try to get it.

Reproducible at commit ba00e4a1b03fa6ca3f2498397c1e6f1628027b5d

It feels like a race condition between image fetching and image loading.
Adding the author of related CLs to consult his opinion:
+Hiroshige for CL https://codereview.chromium.org/1706083002 and 
https://codereview.chromium.org/1706083002

I couldn't reproduce this issue locally, but I found a possible cause: In the following scenario, |ImageResource::m_image| can be null.
1. ImageResource (for the cursor in this case) is loaded normally. At this point, |m_image| is non-null.
2. All clients/observers are removed by e.g. navigating to another page.
3. Resource::prune() is called for the ImageResource from MemoryCache::pruneDeadResources(), but not evicted from the MemoryCache. This occurs the memory pressure is sufficiently high so that pruning is initiated but not so high that the ImageResource is evicted from MemoryCache. After this step, |ImageResource::m_image| is null.
4. Navigating back to the page, and the ImageResource is reused via MemoryCache. Because StyleFetchedImage only adds a client, not an observer. There is no path of re-creating |m_image| when a client is added (there is such code in ImageResource::addObserver() though), so |ImageResource::m_image| is null, as reported above.

A possible fix would be to ensure |m_image| in ImageResource::didAddClient() (or somewhere around addClient()) like we do in ImageResource::addObserver().
I'll create a CL and would like to see whether it fixes the issue on ToT.

@hiroshige, can you please produce "link" and/or "zako" images with your CL in place so that customers can also verify the fix?

Draft CL (under review): https://codereview.chromium.org/2141843003/

dskaram@, could you produce images with the CL above? I'm not familiar with building images for ChromeOS devices and need help...

Uploaded two test images for Pixel 1 and HP Chromebox into the shared Drive folder with the CL in question. Can affected folks please test out this change and verify that it fixes the issue?

https://drive.google.com/open?id=0B7nGgEn7uQ4ubmxwMHJsT3ROMlU

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

commit d415aad374ad81906840afbf4c05f0594f1f581b
Author: hiroshige <hiroshige@chromium.org>
Date: Wed Jul 13 04:41:15 2016

Ensure |m_image| is (re-)created in ImageResource::didAddClient()

After ImageResource is pruned, |m_image| can be turned into null, but is not
re-created when ResourceClient is added to ImageResource later.
We re-create |m_image| when ImageResourceObserver is added in
ImageResource::addObserver().
This CL do the same thing in ImageResource::didAddClient() to ensure |m_image|
is non-null when ImageResource is reused after pruning.

This is regression since ImageResourceClient was split into ResourceClient and
ImageResourceObserver but the |m_image| re-creation logic was put only in the
ImageResourceObserver path and not in the ResourceClient path:
  https://codereview.chromium.org/1706083002
  https://codereview.chromium.org/1728313003

BUG= 618597 ,  587663 

Review-Url: https://codereview.chromium.org/2141843003
Cr-Commit-Position: refs/heads/master@{#405024}

[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

If this is confirmed to fix the issue, we need to backport to beta and stable.

Is it possible to get a version to test for the Asus chromebox by the start of next week? I can consistently reproduce issue on the CN62 chromebox. 

I was not able to create a recovery USB stick that worked. Used both methods (W32 Image burner and Chrome Recovery tool with option 'local image') and two USB sticks.
HP Chromebox did not recognise any of them as recovery disk. Do not know whether both sticks are corrupt or the .bin is not compatible. Either way, I could not verify whether the bug was actually fixed. Hope others are more lucky.

Apologies, the images I shared are not Google-signed images (i.e. cannot act as recovery images). The best way to test them is to use the images you burned onto the USB and boot Chrome OS from that USB. Steps for that:

1. Put the device into the Dev mode (see <https://www.chromium.org/chromium-os/poking-around-your-chrome-os-device#TOC-Putting-your-Chrome-OS-Device-into-Developer-Mode>).

2. Boot (without the USB stick yet) and go into the Developer Console (see <https://www.chromium.org/chromium-os/poking-around-your-chrome-os-device#TOC-Getting-to-a-command-prompt>).

3. When asked for the login and password, type "root" and "test0000" correspondingly.

4. Execute the command "enable_dev_usb_boot".

5. Plug in the USB stick and reboot the device.

6. Press Ctrl+U.

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

commit d415aad374ad81906840afbf4c05f0594f1f581b
Author: hiroshige <hiroshige@chromium.org>
Date: Wed Jul 13 04:41:15 2016

Ensure |m_image| is (re-)created in ImageResource::didAddClient()

After ImageResource is pruned, |m_image| can be turned into null, but is not
re-created when ResourceClient is added to ImageResource later.
We re-create |m_image| when ImageResourceObserver is added in
ImageResource::addObserver().
This CL do the same thing in ImageResource::didAddClient() to ensure |m_image|
is non-null when ImageResource is reused after pruning.

This is regression since ImageResourceClient was split into ResourceClient and
ImageResourceObserver but the |m_image| re-creation logic was put only in the
ImageResourceObserver path and not in the ResourceClient path:
  https://codereview.chromium.org/1706083002
  https://codereview.chromium.org/1728313003

BUG= 618597 ,  587663 

Review-Url: https://codereview.chromium.org/2141843003
Cr-Commit-Position: refs/heads/master@{#405024}

[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/d415aad374ad81906840afbf4c05f0594f1f581b/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

Pri-0 bugs are critical regressions or serious emergencies, and this bug has not been updated in three days. Could you please provide an update, or adjust the priority to a more appropriate level if applicable?

If a fix is in active development, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

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

Hi there guys - I've only found test images for a couple of Chromeboxes and a Pixel in this thread and was hoping to help test the fix. We've got a pilot running with the following devices and was hoping you might be able to link an image that I can test on one of them if possible:

HP Chromebook 14 G4
Dell Chromebook 14

The fix is on the canary channel now. It's best to just move your Chromebooks to that channel (requires going to dev mode first) without any custom builds flying around.

Attaching some instructions. Please ensure after you have moved to canary channel that chrome://chrome shows a version above 54.0.2795.0 as only subsequent versions have this fix. 


http://strawn-04.blogspot.in/2013/12/chromebook-howto-update-to-hidden.html

Hi All, I have updated to Canary on the CN62, so far after an hour I have not had the issue but I will use this all day to confirm. 

That is great!

Question for Google... How quickly can this fix be back-ported to stable-channel? Our users are desperate for this fix. Thanks!

After using all day, I did not have the issue. When can this fix be pushed through the appropriate channels?

Two of us here at Kingston have been using build Version 54.0.2800.2 canary (64-bit), working within Citrix all day and it's been fine, no mouse issues at all so it gets a massive thumbs up from us! :)

If it helps, the two devices we're using are HP Chromebook 14 G4 and Acer Chromebook 14 CB3-431

[Automated comment] Less than 2 weeks to go before stable on M52, manual review required.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Thanks for everyone who confirmed that this fix is indeed fixing the issue.

We are aiming to push this into dev and beta next week and into M52 stable which is coming out on the week of July 31st.

Great to hear @dskaram, thanks for getting this one fixed. 

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

commit c2ef272fdddd2608b0aed1ff0eb0c13fa04d4bc4
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Fri Jul 22 05:49:45 2016

Ensure |m_image| is (re-)created in ImageResource::didAddClient()

After ImageResource is pruned, |m_image| can be turned into null, but is not
re-created when ResourceClient is added to ImageResource later.
We re-create |m_image| when ImageResourceObserver is added in
ImageResource::addObserver().
This CL do the same thing in ImageResource::didAddClient() to ensure |m_image|
is non-null when ImageResource is reused after pruning.

This is regression since ImageResourceClient was split into ResourceClient and
ImageResourceObserver but the |m_image| re-creation logic was put only in the
ImageResourceObserver path and not in the ResourceClient path:
  https://codereview.chromium.org/1706083002
  https://codereview.chromium.org/1728313003

BUG= 618597 ,  587663 

Review-Url: https://codereview.chromium.org/2141843003
Cr-Commit-Position: refs/heads/master@{#405024}
(cherry picked from commit d415aad374ad81906840afbf4c05f0594f1f581b)

Review URL: https://codereview.chromium.org/2175613002 .

Cr-Commit-Position: refs/branch-heads/2785@{#283}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/c2ef272fdddd2608b0aed1ff0eb0c13fa04d4bc4/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/c2ef272fdddd2608b0aed1ff0eb0c13fa04d4bc4/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/c2ef272fdddd2608b0aed1ff0eb0c13fa04d4bc4/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

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

commit 89c778d782211fd938439ce14c9331ff603a0631
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Fri Jul 22 07:43:21 2016

Revert "Ensure |m_image| is (re-)created in ImageResource::didAddClient()"

This reverts commit c2ef272fdddd2608b0aed1ff0eb0c13fa04d4bc4.

BUG=630531,  618597 

Review URL: https://codereview.chromium.org/2175593003 .

Cr-Commit-Position: refs/branch-heads/2785@{#286}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/89c778d782211fd938439ce14c9331ff603a0631/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/89c778d782211fd938439ce14c9331ff603a0631/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/89c778d782211fd938439ce14c9331ff603a0631/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

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

commit 79706ed327e0b6bb0ac98e7ae50c837fe049cce7
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Fri Jul 22 08:37:39 2016

Reland "Ensure |m_image| is (re-)created in ImageResource::didAddClient()"

After ImageResource is pruned, |m_image| can be turned into null, but is not
re-created when ResourceClient is added to ImageResource later.
We re-create |m_image| when ImageResourceObserver is added in
ImageResource::addObserver().
This CL do the same thing in ImageResource::didAddClient() to ensure |m_image|
is non-null when ImageResource is reused after pruning.

This is regression since ImageResourceClient was split into ResourceClient and
ImageResourceObserver but the |m_image| re-creation logic was put only in the
ImageResourceObserver path and not in the ResourceClient path:
  https://codereview.chromium.org/1706083002
  https://codereview.chromium.org/1728313003

BUG= 618597 ,  587663 
TBR=mkwst@chromium.org, yhirano@chromium.org, hajimehoshi@chromium.org

Review-Url: https://codereview.chromium.org/2141843003
Cr-Commit-Position: refs/heads/master@{#405024}
(cherry picked from commit d415aad374ad81906840afbf4c05f0594f1f581b)

Review URL: https://codereview.chromium.org/2169363002 .

Cr-Commit-Position: refs/branch-heads/2785@{#290}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/79706ed327e0b6bb0ac98e7ae50c837fe049cce7/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/79706ed327e0b6bb0ac98e7ae50c837fe049cce7/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/79706ed327e0b6bb0ac98e7ae50c837fe049cce7/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

Hello,

This is great news!!!!  Is there any way to get hard dates on when and where this will be fixed?  I know you have ballpark atm, but I work for a company where we are planning on deploying over 1200 Chromeboxes to our credit department starting 8/1.  We are using vmware horizon through the browser and are receiving the issue in all of our testing.  We are currently putting a few machines into Canary and looks to be working, but we cannot do that on managed devices that are in testing as we have to put them in developer mode.    In order to test in the environment we will have to have it put into beta or dev asap.  We are relying on this fix in order to deploy our devices.  

 Issue 621521  has been merged into this issue.

Can we please merge this fix to M53 branch?

Re#96: It's been merged to M53 per comment 93.

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

commit e70486819d90b5bf2a01b0063c931ee3bc0ffbe1
Author: Hiroshige Hayashizaki <hiroshige@chromium.org>
Date: Sun Jul 24 12:58:12 2016

Merge "Ensure |m_image| is (re-)created in ImageResource::didAddClient()"

After ImageResource is pruned, |m_image| can be turned into null, but is not
re-created when ResourceClient is added to ImageResource later.
We re-create |m_image| when ImageResourceObserver is added in
ImageResource::addObserver().
This CL do the same thing in ImageResource::didAddClient() to ensure |m_image|
is non-null when ImageResource is reused after pruning.

This is regression since ImageResourceClient was split into ResourceClient and
ImageResourceObserver but the |m_image| re-creation logic was put only in the
ImageResourceObserver path and not in the ResourceClient path:
  https://codereview.chromium.org/1706083002
  https://codereview.chromium.org/1728313003

BUG= 618597 ,  587663 
TBR=mkwst@chromium.org, yhirano@chromium.org, hajimehoshi@chromium.org

Review-Url: https://codereview.chromium.org/2141843003
Cr-Commit-Position: refs/heads/master@{#405024}
(cherry picked from commit d415aad374ad81906840afbf4c05f0594f1f581b)

Review URL: https://codereview.chromium.org/2169363002 .

Cr-Commit-Position: refs/branch-heads/2785@{#290}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}
(cherry picked from commit 79706ed327e0b6bb0ac98e7ae50c837fe049cce7)

Review URL: https://codereview.chromium.org/2175163002 .

Cr-Commit-Position: refs/branch-heads/2743@{#696}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/e70486819d90b5bf2a01b0063c931ee3bc0ffbe1/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/e70486819d90b5bf2a01b0063c931ee3bc0ffbe1/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/e70486819d90b5bf2a01b0063c931ee3bc0ffbe1/third_party/WebKit/Source/core/fetch/ImageResourceTest.cpp

The fix has been merged to M-52 (Comment 99) and M-53 (Comment 93).

The next beta and dev builds should have this. I will update the bug with the exact version numbers when they roll out in a day or two.

The Stable channel will get this fix next week as Stable moves to M52 (M51 will not have this fix).

Hello,

Can we please verify the version numbers that the fix will be put in place with in beta / dev?  We are testing for a 1200 chromebox deploy and have a few of the boxes in canary build.  This seems to be working, but we would like to test in beta asap to verify that nothing else is going to be broken and that we are testing as close to stable as we can until the stable release.  

M-54: Fixed on 54.0.2795.0
M-53: Fixed on 53.0.2785.26 (already on cros dev)
M-52: Fixed on 52.0.2743.90 (not yet on cros beta/stable)
M-51: Affected but not fixed
M-50: Not affected

Hi all,

As mentioned above we have confirmed this is fixed for us (couple of devices on canary build = cursor always showing in our Citrix app).  

However just wanted to highlight, a few times since update yesterday (whilst on canary) when opening and closing chromebook lid I have lost the cursor in the Chrome OS (cannot reproduce reliably, very random)!

Version 54.0.2806.0 canary (64-bit)
Platform 8636.0.0 (Official Build) canary-channel kip
Firmware Google_Kip.5216.227.58

Thanks
Phil

Canary is generally highly unstable. We're hoping for the beta build to come out this week so best to delay all subsequent testing for the much more stable beta branch.

Per comment 103, the fix is already on the dev channel. Can we get further confirmation from folks that the dev channel version is also working properly?

Not in position to test on dev at the moment, if it is in Beta next week, can easily test. 

This is working for the most part in DEV but there are still some small issues.  When putting a virtual machine into lock mode the mouse disappears and can't get it back without getting out of the screen.  There are some small issues with the mouse not switching back to an arrow.... example is when in a virtual machine you go over the side of a window and it turns to two sided arrow, it does not turn back to single sided arrow until you go back over that same line.   

re comment #108, I suggest we run tests on beta or stable. Dev channel is notorious for its mouse cursor issues! Beta and stable builds with this fix should start rolling out tomorrow.

Thank you.  Can we get a confirmation when this has been rolled into Beta and Stable so I can verify?  

Thanks for the updates, hope to have this resolved asap

M52 beta and stable with the fix have been released today (52.0.2743.116). Can we get verification from folks on the thread that the problem is solved on these latest builds?

For the most part it is working as expected.  There seems to be a small issue where when pressing CTRL + ALT + DEL from a windows keyboard to put a windows 7 virtual machine into lock screen the mouse disappears intermittently.  We were able to update to this version yesterday and have been testing for since then.

Looking Closer, the version that the machines that are having the issue is 52.0.2743.85.  I cannot get the HP Chromeboxes to update to the newest version of .116.  Will this take care of the issue if we are able to update to the latest .116 version?

Yes. Rollout happens over a couple of days so that faulty updates don't cause big issues in the field. Your devices should be getting the update very soon.

Hello,

Is there a way to force these to our testing machines?  We are basing a lot of the deploy on this fix being implemented.  We have to test for out lines of business and This morning I am still not able to update them to the .116 version.  

Is this fix coming soon for HP Chromeboxes? Omaha shows version 52.0.2743.85 as the current stable version for this model.

When will the fix be put in place for version .116 into the hp Chromeboxes?  If the fix is in this current version it is not working properly as the issue still arises.  Attaching a screenshot from http://cros-omahaproxy.appspot.com/viewer .  The mouse still sporadically disappears when connected to the virtual machine using vmware through browser.

Deleted: Screenshot 2016-08-08 at 2.55.14 PM.png 12.5 KB

	Screenshot 2016-08-08 at 2.55.14 PM.png 12.5 KB View Download

Just checked and it seems the .116 was not pushed out for HP Chromebox. Will check with release team on this.

Confirmed with release team and HP Chromebox will start getting the updates tomorrow. Note that the rollout might take some time to fully complete across all devices.

Thank you for the update.

FYi. M52 Stable update is being rolled out starting this morning

Hello,

Per the bug report they started pushing out yesterday morning to the HP Chromeboxes.  I have not yet been able to get them updated to .116 for the OS fix.  Is there a way to get this pushed out on an expedited manner for us as we need this in order to finish testing the fix so we can get our roll out of 1200 HP Chromeboxes started.  Without this fix in place it could jeopardize our deployment timeline which in turn could force us to hold off on the deployment all together.  Open case #09982182

I don't know of any way to expedite the roll-out. It naturally happens in a staged way and should start showing up on your devices any time now. Not sure if the release team can provide more info here?

Do we have confirmation that all affected customers have received the fix? Can we please verify that this issue is fixed now on all channels (stable, beta, dev)?

Hello,

This looks to be deployed now.  Thank you ... only issue we are seeing is that when locking the virtual machine the mouse disappears still ... This does not happen every time, but when it does we have to restart the connection to the virtual in order to restore the mouse functionality.  We lock the virtual machines by pressing the ctrl + alt + del buttons and selecting lock screen.  Other functionality seems to be working fine.  Thank you for all your work thus far.

We have not observed the issue at all with the Citrix Receiver, have tested over a few days. Thanks for fixing. 

I would like to be able to confirm this fix, but my Dell Chromebox sitll hasn't received the update. I had switched to the beta channel, but now have switched back to the stable.  I've manually checked several times and it keeps saying my device is up to date.  Is it possible that my device is messed up and won't get the update?  Or is waiting this long for the update normal?

I had to recover my Dell Chromebox to get it up to the latest version. Now it's there and I can confirm that the cursor issue has been resolved for me. Thanks.

We had two problems using Citrix Receiver, both had symptoms of a disappearing cursor. See  issue #621521 , which was merged into  issue #618597  (this one).

I can confirm that users no longer complain about a disappearing cursor, so that problem is fixed using the 52.0.2743.116 version. 
But the other one is still there : successive drag-and-drop operations between different windows fail.