This topic describes the issues that may occur when DataV is stuck due to the computer model and browser version.
MacBook User Editor stuck issue
Issue
When you use a MacBook, the CPU utilization increases sharply after you open the DataV editing page. This issue generally occurs in the following scenarios:
Use MacBook when the Retina screen is turned on after higher resolution.
You are using the latest version of the Chrome browser.
Use DataV to edit a visualization application project that contains the basic flat map component.
Causes
A bug (detailed description of this bug) was introduced when the Chrome browser version 66.0.3359.31 on the Mac platform was updated, causing the following problems:
During canvas rendering, the CPU utilization rate soared from 3%~5% occasionally to 100% continuously, causing the frame rate of the front page using the components in the canvas to drop below 8fps, which is very stuck in use.
All web products that use canvas front-end components are affected.
The problem becomes more serious as the number of pixels on the canvas and the number of layers on the canvas increase. As a result, some users are stuck when editing DataV basic flat map components at the standard resolution of 1920 × 1080.
Solutions
This Bug has been fed back to the Google browser development team, and no timetable has been given to solve it. Before the problem is fixed, we recommend that you use the following methods to avoid the problem when using MacBook version Chrome.
If you use an older version of the Chrome browser, we recommend that you use Chrome 57 or later.
Use a different browser, such as Safari.
Temporary editing using a Windows computer.
Possible impacts and solutions after Chrome is upgraded to version 80 and above
Background information
The Chrome80 version released by Google on February 4, 2020 will gradually block third-party cookies, that is, add SameSite=Lax
attributes (Cookies default to SameSite=Lax) to all cookies by default, and refuse to set SameSite=None
attributes (Reject insecure SameSite=None cookies) for insecure cookies, so as to block cross-site request forgery CSRF(Cross Site Request Forgery) vulnerabilities from the source.
How can I determine in advance whether the upgrade of Chrome 80 has an impact on visualization applications?
Open
chrome://flags/#same-site-by-default-cookies
in Google Chrome and set SameSite by default cookies to Enabled.Open
chrome://flags/#cookies-without-same-site-must-be-secure
in Google Chrome and set Cookies without SameSite must be secure to Enabled.Restart Google Chrome and access a DataV project. Check whether all data is returned and displayed as expected.
If yes, updating Google Chrome to v80 does not affect your project.
If no, the update affects your project. You can troubleshoot the issue based on the following scenarios.
Scenario 1: You project uses an API data source
Description: The widget in your project uses an API data source. Requests to call the API contain user logon information in cookies to obtain data from a third-party website.
Impact: Widget data cannot be returned and displayed as expected.
Solution: Determine whether the API requests use HTTPS or HTTP.
Use HTTPS (Chrome 95 or later)
Check whether the settings of Set-Cookie
in the request header contain SameSite=None
and Secure
. If no, add SameSite=None
and Secure
to the settings of Set-Cookie
.
Use the HTTP protocol (Chrome 80 version)
Open the
chrome://flags/#same-site-by-default-cookies
in Chrome and set the SameSite by default cookies to Disabled.Open the
chrome://flags/#cookies-without-same-site-must-be-secure
and set the Cookies without SameSite must be secure to Disabled.Restart your browser.
Use HTTP (Chrome 91 to 94)
Open the
chrome://flags/
in Chrome, search for same in the page, and set the Enable removing SameSite=None cookies to Disabled.Then open the
chrome://flags/
, search for same in the page, and set the Schemeful Same-Site to Disabled.Restart your browser.
Scenario 2: You project is locally deployed based on HTTP
Description: Your DataV project is locally deployed based on HTTP. Impact: Google Chrome v80 intercepts HTTP logon requests. This causes the local project to be unavailable.
Solution: Select one of the following solutions.
Execute the second solution in scenario 1 (using the HTTP protocol).
Transform the HTTP service, purchase a SSL Certificates Service, upgrade the HTTP service to the HTTPS service, and implement the first solution (use HTTPS) in scenario 1.
Roll back Google Chrome to v79 or earlier and disable automatic updates.