yangilbert8@gmail.com

I have confirmed this is an issue from V65 and beyond.  I cannot replicate the issue on v64

Upgraded to the latest dev channel 66.0.3359.31 and latest beta channel 65.0.3325.148  . The issue is still there

David,
any suggestion for this ?

If anybody can file a feedback (alt+shift+i) when this is happening, the logs would help. Please include ' crbug.com/817223 ' in the feedback text and report here so it's properly triaged

I have done what was asked.  I put  crbug.com/817223  as the first line of the comments

to replicate (you can do this on a pixelbook if you like) install the horizon chrome os client and the horizon helper extension and try opening the horizon chrome os client. 

I did just confirm that the issue persists without the horizon helper client by removing the extension and just run the chrome os client for horizon.

Horizon Client is a Pepper web app afaict so not really an ARC app issue. Looks like this app is somehow creating output textures that can't be rendered by the compositor. I'll investigate more tomorrow.

The feedback report is there if needed :
listnr/report/85190906643

> Horizon Client is a Pepper web app afaict so not really an ARC app issue

Sorry for the confusion, I was pointed to this through some ARC++ related channel... I did not verify which one it was (both exist)

Didn't find the time to look at this last week and traveling this week. However, it shouldn't be hard to track down. There's something wrong with how we allocate Pepper backbuffers for this app.

Have filed a feedback (alt+shift+i) when the issue is happening.And put  crbug.com/817223  as part of feedback text .

Atatch the ARC client installation link in web store:  https://chrome.google.com/webstore/detail/horizon-client-for-chrome/pckbpdplfajmgaipljfamclkinbjdnma?utm_source=chrome-app-launcher-search

Stephane,

Can you help finding an owner ?
seems to be a regression in M-65 which is going out of beta soon.

Ilja,
For Pepper potential regression, who might be owning this ? 

There aren't many people still working on Pepper. The first step I guess would be a bisect.

Re #9: I think Chad was looking into something similar recently.

Adding Bernie and Krishna and marking as blocking stable as this impacts all VMware customers in the field and is a regression to previous behavior.

We already started pushing stable, this is too late to block, sorry.

This was put in as a bug on Feb 28 ... Since then we had already pinned our stable channel to v63 as there were other issues in v64.  This is a high priority for our environment to get this fixed.  We have a case open with VmWare (18734492103)  as well which ties back to this crbug.  

Please prioritize this as highest level and get a fix pushed out as soon as possible as it impacts production users and is a regression to current enterprise systems in more than one company.

FWIW, I am glad to take a merge to fix this into 65, assuming the fix is not too large to be safe, if we can get a fix this week we should be able to get it out to 65 next week.

If we don't have a fix by next week we start to get close to slipping to 66 though.

Do we have a list of Pepper using web apps that this could be impacting?

The first comment suggests this breaks VLC for instance, if this is impacting a broad set of web properties that changes the calculus of how we handle this bug and the 65 roll out.

FWIW, I cannot get https://chrome.google.com/webstore/detail/vlc/obpdeolnggmbekmklghapmfpnfhpcndf?hl=en to open a video on 65, need to try another device.

Aha, I updated to 10323.52.0 with Chrome 65.0.3325.148 and I can see the black blinking with VLC. 

With 10323.46.0 I did not see the black blinking, but the VLC app simply did not load properly at all (tries to open a file from the file manager but never opens it). Not clear if this is a 'VLC does not work right after installation, or if .46 was really different behavior. 

As suggested previously we do need to bisect.

Able to reproduce the issue on 65.0.3325.167/10323.58.0 - paine. 
Will provide the bisect.

Raising priority.

Bisect result :
Bad build : 65.0.3297.0/10223.0.0 - Reks
Good build : 65.0.3296.0/10222.0.0 - Reks

CL :
https://chromium.googlesource.com/chromium/src/+log/65.0.3296.0..65.0.3297.0?pretty=fuller&n=10000

Confirming the repro. I've reproduced the problem on eve with VLC and with the Horizon Client.

Re #27: Wow, how did you do that so quickly?

Re #17:
> Re #9: I think Chad was looking into something similar recently.

Yes, for the ARC Amazon Kindle app. See https://bugs.freedesktop.org/show_bug.cgi?id=105332 . Even though this is a Pepper app, and the other bug is an ARC app, the symptoms look similar.

In the Freedesktop bug, Intel diagnosed the issue as an application failure to synchronize the app's multiple GL contexts between texture uploads. With that hint, and looking at songsuk's bisection range, the below commit stands out from the rest.

Just a wild guess.

https://chromium.googlesource.com/chromium/src/+/c94b8de93784783fcc3486dc3ed90b1f6e6f8560%5E%21
commit    c94b8de93784783fcc3486dc3ed90b1f6e6f8560
author    Sunny Sachanandani <sunnyps@chromium.org>	Sat Dec 16 03:30:30 2017
committer Commit Bot <commit-bot@chromium.org>	Sat Dec 16 03:30:30 2017
subject   gpu: Simplify CHROMIUM_sync_point API.

+sunnyps author of suspected CL.

Verified the fix on 65.0.3325.184 /10323.62.0 - Reks

Is the fix being implemented immediately to all models?  Or do we need to wait for v66 release?

re #34: the fix will apply to all devices on M-65

Having to wait for v66 release will be another 6 weeks of companies dealing with this issue.  In an enterprise environment that is not acceptable if there is a possibility to push out a patch in the mean time.

Thank you @ comment 35  It is greatly appreciated.

Now that we have a fix, and it is merged into 65, the next 65 should resolve the issue.

The next 65 stable is making its way through the release process now.

At this point I think we can consider this fixed, and even verified per comment 32.

Is there a way for me to verify now?  I currently have an Asus C302CA that is in beta channel on version 65.0.3325.167 (Official Build) beta (64-bit)

I am waiting for the .184 release to test.  I also have a Pixelbook if it is easier to test on that machine. 

I just  put the Asus in Beta about 5 minutes ago and only updated to .167 release.

Able to reproduce the issue on 66.0.3359.43/10452.19.0 - Link.  Mark as "Fixed" and will verify the fix on M66. 

Merge to M66 was uploaded this morning: https://chromium-review.googlesource.com/c/chromium/src/+/972503

66.0.3359.43 (Official Build) dev (64-bit)
tested and still issue persists with the horizon chrome os application

Is there a way to test this without going into developer mode on my Chromebook?

The merge wasn't picked up in the M66 beta cut, so you won't see it fixed there. However, it's on M65, so try that if you'd like.

Verified the fix on Chrome 66.0.3359.48/CrOS 10452.22.0 - Link/Peppy

Currely latest beta channel is 65.0.3325.167 and the issue is still there.

Current Stable Channel for pixelbook is .184 build and is fixed in that build.

Deleted: Screenshot 2018-03-25 at 9.39.39 PM.png 62.1 KB

	Screenshot 2018-03-25 at 9.39.39 PM.png 62.1 KB View Download