dmunish opened a new issue, #21625:
URL: https://github.com/apache/echarts/issues/21625

   ### Version
   
   6.1.0
   
   ### Link to Minimal Reproduction
   
   https://codepen.io/Danish-Munib/pen/raWzBYG
   
   ### Steps to Reproduce
   
   1. Load core echarts v6.1.0 alongside the latest version of echarts-gl.
   2. Initialize a standard 2D chart (such as a basic 2D bar graph) using 
echarts.init().
   3. Enable the native toolbox 'saveAsImage' feature in the chart 
configuration options.
   4. Render the chart in a classic browser viewport.
   5. Click the "Save Image" option icon within the chart toolbox to trigger a 
canvas export.
   
   ### Current Behavior
   
   The image export task instantly fails and the tool icon disappears, throwing 
an unhandled TypeError in the browser console. The image does not download. 
   
   This crash surfaces globally even on completely standard 2D charts that do 
not utilize any WebGL/3D series. The moment the export pipeline is invoked, 
echarts-gl intercepts the layer processing sequence but runs into an unhandled 
undefined reference:
   
   Uncaught TypeError: Cannot read properties of undefined (reading 'length')
       at findAndDrawOtherLayer (echarts-gl.js:18883:40)
       at zr.painter.getRenderedCanvas (echarts-gl.js:18903:9)
       at ECharts2.renderToCanvas (chunk-QDOBHZKM.js:24623:22)
       at ECharts2.getDataURL (chunk-QDOBHZKM.js:24669:84)
       at ECharts2.getConnectedDataURL (chunk-QDOBHZKM.js:24762:21)
       at SaveAsImage2.onclick (chunk-ZM7VAYIS.js:36815:21)
   
   ### Expected Behavior
   
   The chart layer composition pipeline should execute seamlessly. The canvas 
element should compile into a valid data URL string, and the resulting image 
should download safely without throwing runtime script errors.
   
   ### Environment
   
   ```markdown
   - OS: Microsoft Windows 10
   - Browser: Brave v1.90.124, based on Chromium 148.0.7778.179
   - Framework: Vanilla JavaScript / Native DOM Execution Context
   ```
   
   ### Any additional comments?
   
   ## Isolation Analysis:
   1. This is a regression strictly introduced in core v6.1.0. Reverting the 
core package to v6.0.0 resolves the issue.
   2. The failure is completely isolated to the global interception mechanics 
of the GL extension. If the `echarts-gl` script tag is commented out/omitted, 
the standard 2D 'saveAsImage' toolbox feature functions normally. 
   3. Visual 3D scene compilation loops (such as bar3D with auto-rotation) 
operate correctly in v6.1.0, proving that underlying WebGL context creation and 
frame state updating work fine. 
   
   ## Root Cause Hypothesis:
   Upon execution, `echarts-gl` globally monkey-patches ZRender's canvas 
exporting mechanics (`zr.painter.getRenderedCanvas`) via its internal 
`findAndDrawOtherLayer()` utility to search for active 3D view layers. The core 
refactoring targets introduced in v6.1.0 appear to have updated or detached 
internal painter layer structures. Because `echarts-gl` lacks a structural 
fallback check when reading these newly formatted core collections, it attempts 
to access a `.length` parameter on an unallocated `undefined` reference, 
breaking image exports uniformly across the entire ecosystem.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to