Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

plotly.min.js overrides Promise #1032

Closed
zllovesuki opened this issue Oct 13, 2016 · 6 comments
Closed

plotly.min.js overrides Promise #1032

zllovesuki opened this issue Oct 13, 2016 · 6 comments
Labels
bug something broken
Milestone

Comments

@zllovesuki
Copy link

zllovesuki commented Oct 13, 2016

When using plotly.js with Bluebird (global scope, without Bluebird.noConflict()), loading plotly.js seems to overrides the Promise.

Bluebird 3.4.6
Plotly.js 1.17.3
Chrome 53.0.2785.143 m (64-bit)

Try this:

  1. Load Bluebird
  2. Load Plotly.js
  3. Promise.all([]).spread()

Expected Results:
3 returns a Promise

Actual Result:
Promise.all(..).spread(..) is not a function

@zllovesuki
Copy link
Author

maybe related to #955

@etpinard
Copy link
Contributor

Yep, same problem as #955

Importing plotly.js before Bluebird should solve the issue.

@etpinard etpinard added the bug something broken label Oct 14, 2016
@etpinard etpinard added this to the v2.0.0 milestone Oct 14, 2016
@etpinard etpinard changed the title plotly.min.js seems to override Promise plotly.min.js overrides Promise Jan 6, 2017
@etpinard
Copy link
Contributor

#2994 will add a handler for window.PlotlyConfig.MathJaxConfig as a way to configure MathJax "on load".

I'm thinking we could similarly add a handler e.g window.PlotlyConfig.noPromisePolyfill to skip over this line

require('es6-promise').polyfill();

on load.

@archmoj
Copy link
Contributor

archmoj commented Jan 14, 2021

This might be fixed by #5358.

@alexcjohnson
Copy link
Collaborator

This one we should explicitly test (manually, once, I don't see it as requiring a CI test) before closing.

@archmoj
Copy link
Contributor

archmoj commented Jan 19, 2021

This one we should explicitly test (manually, once, I don't see it as requiring a CI test) before closing.

Tested. It is fixed on master.

@archmoj archmoj closed this as completed Jan 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug something broken
Projects
None yet
Development

No branches or pull requests

4 participants