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

Issue 831529 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Nov 15
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

LEGO Education WeDo 2.0 not able to start on Chrome 66

Reported by claus....@gmail.com, Apr 11 2018

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Platform: Chrome OS

Steps to reproduce the problem:
We have an issue with two of our Chromebook applications on the Chrome 66 beta release.

The application is using Webgl and is made for chromebooks and many schools/students is using it. The applications can not finish loading on Chrome 66, both extensions are working on Chrome 65 and previous versions.

It is repeatable in Chrome 66 on both windows, mac and chromebook.
The Chrome extension can be seen here (the build here only allows launching on Chromebooks. We can send you a modified build if you need builds for other platforms)
https://chrome.google.com/webstore/detail/wedo-20-lego%C2%AE-education/pflionopdgpjckjkafnlamfmonjhccdh?hl=en

We have tracked the issue to being caused by our splash screen.
The splash screen in our application is a fairly standard div element with an image and a progress bar – the div ‘covers’ the webview element containing the webgl code.

Our application is fairly large and can take some time to load, so we need to be able to run both the progress bar splash screen and to be able to initialize the webgl webview in the background. This approach has been working fine in Chrome up to and including Chrome 65, but is not working for us in Chrome 66.

As far as we can tell, the problem for our application in Chrome 66 is, that apparently some DOM optimizations have been added in 66 compared to Chrome 65.
In 66 when the element is not visible it is not given any resources – and then the Unity webgl does not complete loading.

We have identified that we can work around this optimization by moving the splash screen in the DOM so it does not completely hide the webview – if a single pixel of the webview is visible it is enough for it to get resources and the application can finish loading the webgl in the background while animating the splash screen and progress bar in the foreground.

Can you please advise if there is a better/more correct way of allowing the webview to get resources even if it is running in the background – and maybe point us to a resource describing how this can be done?

What is the expected behavior?

What went wrong?
Please see above description. 

Did this work before? Yes Chrome 65.

Chrome version: 66.0.3359.79  Channel: beta
OS Version: 66.0.3359.79
Flash Version: Shockwave Flash 29.0 r0
 

Comment 1 by claus....@gmail.com, Apr 11 2018

This issues also applies til LEGO Education EV3 Mindstorms. 

Comment 2 by laforge@google.com, May 10 2018

Components: Blink>Canvas Blink>WebGL
Owner: fsam...@chromium.org
Status: Assigned (was: Unconfirmed)
Externally reported bisect range: https://chromium.googlesource.com/chromium/src/+log/b78e0928ee88da3ceda0466d018d33ce9d98e91a..8ca98dc3735850f82905392fc2eb5e220bfe38a0

With the comment that "the user found that by applying “width:80%” to the splashscreen.png element, the unity runtime will start running (as if it's a matter visibility) in Chrome 66."

@Fady - I'm not seeing anything obviously jump out, could it be related to your CL?

https://chromium.googlesource.com/chromium/src/+/a41e9d414caf98f688bb648d4ac2bbd9c1056cbf

Comment 3 by kbr@chromium.org, May 11 2018

Cc: kainino@chromium.org jdarpinian@chromium.org
Labels: -Type-Bug Type-Bug-Regression
Submitter: is this bug reproducible on any other platform except Chrome OS? If it is, then could you please email fsamuel@ and kbr@ (at google dot com) a link to a build which will run on other platforms? It will probably be easier for us to diagnose this on a different platform, in particular Linux. Thanks.

Comment 4 by kbr@chromium.org, May 14 2018

Labels: -Pri-2 Pri-1
Fady: unfortunately it sounds like the customer's problem is only reproducible on ChromeOS. Could I ask you to triage this urgently? Feel free to downgrade again if the cause is understood and it isn't that urgent or widespread an issue. Thanks.

Comment 5 by claus....@gmail.com, May 14 2018

Sorry, I got the question wrong about platforms. Our dev. team can also reproduce this os Windows and OSX. I will ask them to follow up on your questions tomorrow morning CET. 
OK, I will investigate. Thanks!
Yes, it's possible for my CL to cause this. It still seems like this Chrome app won't load. I tried turning off surface sync and it still doesn't load. I'll investigate further.

Comment 8 by laforge@google.com, May 19 2018

Cc: lafo...@chromium.org
Components: -Blink>Canvas Blink>Scheduling
Any updates?
Hey folks, did this ever get closed out?
I didn't really investigate further because I couldn't pin it down to a surface sync bug and it kind of got lost in the midst of other bugs. Is this still an issue?
Status: WontFix (was: Assigned)
I haven't heard a response here in a while so I'm marking as WontFix. Please reopen if this is still an issue.

Sign in to add a comment