Skip to content

Use correct parent document when necessary: fixes 702 #2 #758

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

Closed
wants to merge 115 commits into from

Conversation

nielsenb-jf
Copy link
Contributor

This pull request fixes the issues noted in issue 702. Essentially, if Plotly was provided an element in a different window or tab, the plot would not be styled correctly and interactivity (hovers, drag zoom, etc.) would not work.

The following are the big changes to fix this issue:

  • Graph divs now keep a reference to their 'parent' document in the `_document' property.
  • Styles are now injected to the parent document on the first call to Plotly.plot.
  • Anything that draws over a document for interactivity purposes (eg. dragcovers), now uses the _document reference to ensure it is drawn in the correct document.
  • Notifiers now require a graph div as the first argument so that notifications are rendered in the correct place

nielsenb-jf and others added 30 commits July 12, 2016 15:05
This fixes the issue with the dragcover not being appended to the
correct child when the plot is rendered on a window other than the
parent.
This fixes the issue with range slider events being tied to the parent
window, as opposed to the child, when rendering to a div in a child
window.
This fixes the assumption that the plot should be sized based on the
window Plotly was instantiated in, instead of the window Plotly is
drawing the plot in.
The previous behavior was to inject CSS into the document the Plotly JS
is loaded in. This causes plots rendered in a different document to not
be styled correctly. Now, the CSS is injected into the correct document
during Plotly.plot.
files.

Also change the built plotcss file to export the rules, not inject them.
- so that plotting code - which relies on marker.line.width to
  set the effective 'bargap' does not error out
- broken since plotly#124
This fixes the issue with the dragcover not being appended to the
correct child when the plot is rendered on a window other than the
parent.
- before dd2251d
  bar for non-numeric size were excluded from the calcdata,
  which led to wrong bar widths in traces with gaps. However,
  this made setPositions stack non-numeric bars.
…AF never stops; 2) scene2d.destroy should destroy the traces

(cherry picked from commit 8f6f2dd)
The _plotCSSLoaded property is set to true after injecting the CSS.
…ed in.

This reference is used where necessary to ensure functionality when
plotting to a window other than the one Plotly was instantiated in.
'inserts styles on initial plot' - Deletes all plotly CSS in the
document (in case other tests have run previously), does a plot, and
verifies the CSS has been injected.

'inserts styles in a child window document' - Creates a plot in a child
window, and makes sure the CSS has been injected. The child window is
then closed, no cleanup required.

'does not insert duplicate styles' - Deletes all plotly CSS in the
document, plots to the graph div twice, and ensures the required Plotly
CSS only occurs once.
This fixes the issue with notifications not appearing in the correct
window when plotting to a child window. The notification is now appended
to the body of the document the graph div is a child of.
@etpinard
Copy link
Contributor

Hmm. Something went wrong with your git rebase. I'll pull down your branch and rebase the commits when I get the time this week.

@etpinard etpinard added feature something new status: in progress bug something broken labels Jul 20, 2016
@nielsenb-jf
Copy link
Contributor Author

Is it griping about "Commit 212d5f... being a merge, but no -m option given"?

If you figure out how I broke that, I'd love to hear it so I can avoid this again.

@etpinard
Copy link
Contributor

@nielsenb-jf I squashed together all commits in your child_window_fixes branch and push to a new branch squash-child-window. I proposed closing this PR and opening a new one off my squash-child-window branch. This would lead to some good and bad news:

Good news: you'll get one authoring commit
Bad news: you'll only get one authoring commit

But one thing is sure: merging 115 commits of git frustration ⏫ won't happen.

Alternatively, you can also try:

  • fetching the squash-child-window branch unto your fork
  • run git reset HEAD^ to reset the BIG squashing commit 4cb2c7c
  • git add and git commit your work into multiple commits
  • and then git push -f unto your child_window_fixes branch

Thanks again for your hard work!

@nielsenb-jf
Copy link
Contributor Author

I'm on board for one "BIG ASS CHILD WINDOW COMMIT". Thanks for your help!

New PR

@etpinard etpinard added type: duplicate and removed status: in progress bug something broken feature something new labels Jul 21, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants