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
Viewer Pane not working #6737
Comments
|
Does not repro:
Repros
So whatever's going on here looks like it's specific to R 4.0 and Windows. |
|
Upon further investigation: The viewer pane works fine with other HTML widgets. For example networkd3: Also, the Viewer pane isn't failing to load leaflet. It is loading, but Leaflet itself is throwing a JavaScript exception on startup. So this appears to be a bug in the R 4.0 version of the leaflet package. Please open an issue over there: |
|
I think there might be something more to this, @jmcphers. The exception is a red herring, it's a caught exception. I can repro with DT and jcheng5/d3scatter, but not with DiagrammeR. Shiny works fine--including apps with Leaflet and DT. Not seeing much of a pattern so far. Strangely, the rsession uses more and more CPU each time--each additional run seems to permanently spike one of my CPUs, in the rsession.exe process. As if each attempt causes another thread to be launched that then gets into an infinite loop, or something (I'm not set up with a debugger on Windows so I couldn't tell you the call stack). When I look in RStudio devtools, the DOM inspector shows an HTML document that seems to contain the correct Once in a great while, it succeeds, I don't know why. |
|
Thanks @jcheng5, that's very helpful. We found another data point which is that the viewer pane is also usually broken for |
|
Hi there, I have a very similar issue with plotly:
When I run a simple plotly plot (like this https://plotly.com/r/line-charts/) no error is raised in the console, the view pane is focused, but remains blank and the RStudio rsession CPU usage spikes (and remains high regardless of what I do, until I exit RStudio). I definitely can second the impression, that the viewer pane gets stuck in a loop. I tried this a thousand times and for some reason managed to render one plot on one occasion. Also, the plotly plot works just fine from my browser (like in the link above). UPDATE: The issue does not occur with R 3.6.1 and RStudio 1.2.5042 |
|
Some more information from a debugger:
Here is a trace from one of the threads: The thread callstack always has This makes me think of the known freeze on macOS with |
|
It seems pretty likely that this is related since the spinning threads appear to be trying to open sockets. Still not clear to me why we would be triggering a socket open here. |
|
Main thread callstack on first errant thread creation: |
|
More interesting data points... The problem is not related to or specific to HTML widgets. If the Viewer Pane is disabled, the CPU usage goes away. So it's certainly related to viewing, not creating, the widgets. The Viewer Pane is effectively loading an iframe that, in turn, is taking advantage of R's HTTP help server to render a copy of the widget HTML that has been placed in the session temporary directory. The help server has a feature that allows it to render content from the session temporary directory (tmpdir), so we form a URL that looks like this: If the Viewer Pane is disabled and that URL is visited in a browser, it will also fail to load and spike the R session's CPU usage. So the problem isn't RStudio's Viewer pane or other UI, either. The conclusion we can draw from this is that the bug arises when R's HTTP help server is embedded inside an RStudio R session. This combination somehow causes the HTTP help server to fail to serve most content inside the session temporary directory. We could probably cut the Gordian knot here by just proxying the requests to the session temporary directory ourselves instead of asking R to do it, but it'd be nice to understand why this happens. |
|
Hi, Exactly the same experience and setup as @yankodev, but with mapview (2.5.0). All working fine in R 3.6.3. (RStudio 1.2.5042)
|
|
In Rhttpd.c there's the following line: /* debug output - change the DBG(X) X to enable debugging output */
#define DBG(X)I redefined this to |
|
Another interesting tidbit from Rhttpd.c: /* finalize a request - essentially for HTTP/1.0 it means that
* we have to close the connection */
static void fin_request(httpd_conn_t *c) {
if (!IS_HTTP_1_1(c))
c->attr |= CONNECTION_CLOSE;
}If you remove the conditional (so it always adds |
|
Hmm. That code hasn't changed in 11 years! Perhaps the culprit is a failure to close the connection somewhere else? I'll pick this up again next week. |
|
This is getting more and more mysterious. The good news is that I've found what I think is clearly a bug in Rhttpd.c, and it's easy to fix. However, the bug is 8 years old. So I don't know why we wouldn't have seen this before. There's this This flag is written in On non-Windows, this presumably works fine. On Windows, it's not as simple. To fix this, you can just |
|
Now that I said that... I'm not sure why returning early from However, if somehow After writing the above, it occurred to me that |
|
Thank you jcheng5 for pointing me to this threat from #422. I can completely confirm your observation of |
That's very possible as R 4.0 uses a new C++17 compiler. It is indeed mysterious that we haven't seen this before. It's also mysterious that this only happens when R is embedded in RStudio as this shouldn't affect any of the codepaths above. Maybe something about what we're already doing on the main thread affects the timing adversely such that this happens almost all the time? It sounds like we probably need to report this upstream, but in the meantime I think we can work around this on our end by serving files ourselves. |
|
I'm able to reproduce it in RGui, but you kind of have to go out of your way. When you launch an htmlwidget in RGui, it just calls But if you do it using RGui, it reproduces:
(No disagreement about serving the file yourselves!) |
|
Is it worth filing a bug report for R on this? |
|
Verified Fixed on: Windows 10 Pro, Desktop, R.4.0.0, RStudio version: 1.3.957-1 Html widgets are now being previewed/displayed successfully in the Viewer pane. |
|
I'm having the same issue currently. What is the fix? |
|
The fix is to download the preview version of RStudio. You can get it here: |
|
The underlying R bug is now fixed in R-devel: wch/r-source@1ed9656 Thanks everyone who reported it, and @jmcphers for the quick workaround! |
|
Re-opening as it looks like we're seeing another manifestation of this issue reported in #6893. From that ticket: "Referring to Viewer Pane not working issue see #6737 the underlying R bug is fixed in R-devel (1.3.958-3) but the show in the new window function in the viewer pane is not working". Confirmed that this issue is still occurring in RStudio Version 1.3.959. |
|
Closing this ticket. We're going to treat the behavior reported in #6893 as a new issue and look to address it in a future release. |
|
Hi! Setting options(viewer=NULL) opens browser directly, but the problem remains. In plain R everything works flawlessly. R version 4.0.3., RStudio verions 1.3.1093, Ubuntu 18.04 |
|
I'm still having this exact issue. Not sure what the exact cause is. I am running RStudio Juliet Rose, and here is my session info: When I open the map in browser, it works fine. The base map from 'AddTiles()' is the only part which is blank, if I add polygons/points they display on the map To reproduce, just run but I think it might be specific to some of my versions. Is there something I should try and update? |



System details
Steps to reproduce the problem
Run any command that sends an interactive output to the Viewer pane.
For example,
or
Describe the problem in detail
The commands run without error but the Viewer pane remains blank (see screenshot below).
Note: running the same command from an R session in the terminal works fine.
Describe the behavior you expected
In these specific examples, interactive maps should appear.
Diagnostics Report
diagnostics-report.txt
(Potentially) Related Issues
#6381
The text was updated successfully, but these errors were encountered: