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

Very bad performance of RMarkdown in Firefox #483

Closed
ischurov opened this issue Mar 7, 2016 · 9 comments
Closed

Very bad performance of RMarkdown in Firefox #483

ischurov opened this issue Mar 7, 2016 · 9 comments

Comments

@ischurov
Copy link

ischurov commented Mar 7, 2016

I have RMarkdown document with several Plotly 3D charts. I convert it to HTML using RStudio's knitr and get HTML. This HTML file cannot be opened with Firefox: the browser starts complaining about unresponsive script, eats a lot of memory and finally hangs. The same charts created by Jupyter / IPython Notebook and converted to HTML can be opened with Firefox.

You can see the testcase here.

  1. Original Rmd.
  2. HTML from Rmd that hangs my Firefox.
  3. Translation to Jupyter/IPython.
  4. HTML file from IPython that can be opened with Firefox.

I'm using Mac OS X and Firefox 44.0.2.

It seems to be more-or-less Firefox-specific issue as the test HTML file can be opened with Google Chrome and Safari.

@equastatjamesw
Copy link

equastatjamesw commented May 26, 2016

Opening this in Firefox 46.0.1 on Windows 10 I receive the warning message:
"mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create"
followed by an out of memory exception after allocation of more than 1GB.

The same issue happens for me when opening any HTML-Widgets based plotly charts saved to .html file from RStudio. It appears that with a clean restart of Firefox I can often get one plot to load properly, although it is still very slow and consumes more than 1GB of RAM whereas opening the same .html in Chrome or Edge is fast and uses less than 100MB.

The crash/exception issue with Firefox does not appear to happen when I manually replace the reference to plotly.js version 1.10.1 used by RStudio with plotly.js version 1.12. I do still receive the warning message regarding line 3419 in plotly.js but it is no longer unstable in Firefox for me.

3418 if (Buffer.TYPED_ARRAY_SUPPORT) {
3419 Buffer.prototype.proto = Uint8Array.prototype

@ManuelZ
Copy link

ManuelZ commented Feb 4, 2017

I'm having the same problem with Firefox 51.0.1 and Plotly 4.5.6 for R.

@mbannert
Copy link

same here... any news on the issue? Problems seem to persist with FF 52.0 .

@cpsievert
Copy link
Collaborator

note to self: hoping plotly/plotly.js#1525 fixes this

@rreusser
Copy link

rreusser commented Apr 7, 2017

If it's the same source, the "mutating the [[Prototype]]…" warning comes from d3 and won't be fixed. My best understanding is that it's a warning about best practices, but not one that has a measurable effect relative to a library like plotly.js. (in particular because gl3d plots are hardly (if at all?) using d3)

I can definitely confirm that the page is perfectly snappy in chrome and very problematic in firefox.

@cpsievert
Copy link
Collaborator

cpsievert commented Apr 7, 2017

Ok, this definitely has something to do with self_contained: true on Firefox as mentioned in #721. Here is a more minimal example that at least seems to render in Firefox, though it hogs up to 5GB of RAM on my system!

---
title: "Open me in Firefox if you dare"
output: 
# set `self_contained: false` and the problem goes away
  html_document:
    self_contained: true
---

```{r, message = FALSE}
library(plotly)
plot_ly()
```

@DarioS
Copy link

DarioS commented Jun 7, 2017

Thanks for the implicit tip. It worked for me once I used self_contained: false but I'd prefer if it worked when self_contained: true.

@Kabouik
Copy link

Kabouik commented Oct 12, 2017

I can confirm it works with self_contained: false, but would prefer it to work with true as well. Most of all, there should be a big warning about Firefox incompatibility (especially as self_contained: true is the default), since it's a major browser. I don't use it myself, and only realized there was an issue with my report when someone asked me "What figures?" when trying to read it.

@cpsievert
Copy link
Collaborator

I have a feeling this issue is related to the fact that pandoc <2.0 used data URIs to embed dependencies, but pandoc >2.0 uses cleartext.

Closing since upgrading to pandoc >2.0 seems to fix #483 (comment), but please reopen if you find more (related) problems

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

No branches or pull requests

8 participants