Fix (Saving Images): Fixed a window proxy issue when saving images in the micro-frontend framework.

[YaoKaiPeng]

Fix (Saving Images)

Added the pickEventView function to handle the window proxy issue in the micro-frontend framework, ensuring that the save image event is triggered correctly in different environments.

Brief Information

This pull request is in the type of:

• bug fixing
• new feature
• others

What does this PR do?

This PR fixes an issue where the save image functionality failed in micro-frontend environments due to window proxy interference. The introduced pickEventView function correctly identifies the appropriate view context for event handling, ensuring consistent behavior across different sandboxed or proxy-ed window environments.

Fixed issues

Details

Before: What was the problem?

In micro-frontend architectures (e.g., using Module Federation or iframe-based isolation), the window object is often proxied or sandboxed. When triggering the save image event, the original window reference was used directly, leading to failures in event dispatching or incorrect DOM context resolution. This caused the save image feature to be non-functional or inconsistent across environments.

After: How does it behave after the fixing?

With the addition of the pickEventView utility function, the system now dynamically resolves the correct view context (e.g., the actual window or document from the current execution context) before triggering the save image event. This ensures the event is properly dispatched and handled regardless of the micro-frontend sandboxing mechanism. The save image functionality now works reliably in all supported environments, including isolated or proxied frames.

Document Info

One of the following should be checked.

• This PR doesn't relate to document changes
• The document should be updated later
• The document changes have been made in apache/echarts-doc#xxx

Other information

This fix is particularly important for users adopting ECharts in micro-frontend setups using tools like Webpack Module Federation, Single-SPA, Micro-App, or custom sandboxing solutions. The pickEventView function is designed to be lightweight and reusable across similar contexts.

[echarts-bot]

Thanks for your contribution!
The community will review it ASAP. In the meanwhile, please checkout the coding standard and Wiki about How to make a pull request.

Please DO NOT commit the files in dist, i18n, and ssr/client/dist folders in a non-release pull request. These folders are for release use only.

[plainheart]

I am not familiar with the micro-frontend framework. Instead of dispatching a click event, does $a.click() work in that environment?

[YaoKaiPeng]

Hi, happy to discuss this further!

In micro-frontend environments, window is often a proxy object (e.g., in qiankun, Micro-app, etc.), which can cause issues when creating MouseEvent with new MouseEvent(..., { view: window }) — for example, throwing errors or behaving unexpectedly.

I believe the key point isn't whether to use element.click() or dispatchEvent, but rather: which actual window object should be used as the view when creating the event.

That’s why this PR replaces document.defaultView with pickEventView() — a safe utility that:

1. Tries to use window.rawWindow (available in frameworks like Micro-app, where window.proxy holds the real rawWindow).
2. Falls back to document.defaultView if that’s accessible.
3. Finally defaults to window if all else fails.

This ensures the MouseEvent always has a valid, real window as its view, regardless of whether window is a proxy — making the event creation robust in micro-frontend setups.

Importantly, this change doesn’t alter how events are dispatched (we still use dispatchEvent), but it significantly improves reliability by ensuring the correct view context is used.

This makes ECharts more resilient in micro-frontend applications without introducing any behavioral changes.

Thanks for raising this question — happy to discuss further! 😊

[plainheart]

Thanks for your explanation. I mean, we can try using $a.click() rather than manually creating and dispatching a click event, since $a.click() doesn't need to pass the window object. If this works in micro-frontend frameworks, I think we can remove this code block.