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

Viewer Pane not working #6737

Closed
4 tasks done
tiernanmartin opened this issue Apr 26, 2020 · 30 comments · Fixed by #6804
Closed
4 tasks done

Viewer Pane not working #6737

tiernanmartin opened this issue Apr 26, 2020 · 30 comments · Fixed by #6804

Comments

@tiernanmartin
Copy link

@tiernanmartin tiernanmartin commented Apr 26, 2020

System details

RStudio Edition :  Desktop
RStudio Version :  1.2.5042
OS Version      :  Windows 10 x64
R Version       :  R version 4.0.0 (2020-04-24)

Steps to reproduce the problem

Run any command that sends an interactive output to the Viewer pane.

For example,

library(mapview)
  
 mapview(breweries)

or

library(leaflet)

m <- leaflet() %>%
  addTiles() %>%  # Add default OpenStreetMap map tiles
  addMarkers(lng=174.768, lat=-36.852, popup="The birthplace of R")
m  # Print the map

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.

image

Describe the behavior you expected

In these specific examples, interactive maps should appear.

Diagnostics Report

diagnostics-report.txt

(Potentially) Related Issues

#6381

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Apr 27, 2020

Does not repro:

  • R 3.6.1, RStudio 1.3.688, Windows
  • R 3.6.1, RStudio 1.2.5042, Windows
  • R 4.0.0, RStudio 1.4.215, MacOS

Repros

  • R 4.0.0, RStudio 1.2.5042, Windows
  • R 4.0.0, RStudio 1.3.947, Windows
  • R 4.0.0, RStudio 1.4.237, Windows

So whatever's going on here looks like it's specific to R 4.0 and Windows.

@jmcphers jmcphers modified the milestone: v1.3 Apr 27, 2020
@jmcphers
Copy link
Member

@jmcphers jmcphers commented Apr 27, 2020

Upon further investigation:

The viewer pane works fine with other HTML widgets. For example networkd3:

image

Also, the Viewer pane isn't failing to load leaflet. It is loading, but Leaflet itself is throwing a JavaScript exception on startup.

image

So this appears to be a bug in the R 4.0 version of the leaflet package. Please open an issue over there:

https://github.com/rstudio/leaflet

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented Apr 28, 2020

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 <head>, but no <body>. I tried to use the Network tab to see whether the HTTP response looks correct, but when I click on a request the devtools panel goes blank. (RStudio 1.4.218)

Once in a great while, it succeeds, I don't know why.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Apr 30, 2020

Thanks @jcheng5, that's very helpful. We found another data point which is that the viewer pane is also usually broken for DT::datatable on R 4.0.0 for Windows (see #6786) so there's definitely a pattern here. I'm baffled as to why this could be specific to Windows (and especially why it could be specific to R 4.0.0) but there's clearly an underlying cause here.

@jmcphers jmcphers added this to the v1.3-patch milestone Apr 30, 2020
@yankodev
Copy link

@yankodev yankodev commented May 1, 2020

Hi there, I have a very similar issue with plotly:

  • Windows 10 x64
  • R 4.0.0, RStudio 1.2.5042

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

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 1, 2020

Some more information from a debugger:

  • The main rsession thread is not responsible for this behavior, and R itself is not busy. While in this state you can still interact with R as usual.
  • The additional CPU cycles are consumed by some additional threads that are getting created in this scenario. Each time you plot certain HTML widgets, more of these threads appear, spinning and consuming more cycles.

Here is a trace from one of the threads:

image

The thread callstack always has R_init_internet on it; sometimes this is the last call, and sometimes it also has MSWSOCK as above.

This makes me think of the known freeze on macOS with socketSelect: #6692 -- but that's macOS only and it is not clear why R would be doing a socketSelect here.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 1, 2020

R_init_internet last changed about 3 months ago with this commit, which added support for multiple socket connections:

wch/r-source@ca1cc37

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.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 1, 2020

Main thread callstack on first errant thread creation:

   0  Id: 1060.bcc Suspend: 1 Teb: 0000005f`604fe000 Unfrozen
 # Child-SP          RetAddr           Call Site
00 0000005f`615f9958 00007ffe`a0df5fe9 ntdll!NtWaitForMultipleObjects+0x14
01 0000005f`615f9960 00007ff7`f424b07d KERNELBASE!WaitForMultipleObjectsEx+0xf9
02 0000005f`615f9c60 00007ff7`f309674d rsession!rstudio_boost::this_thread::interruptible_wait(void * handle_to_wait_for = 0x00000000`00000368, struct rstudio_boost::detail::mono_platform_timepoint * timeout = 0x0000005f`615f9ed8)+0x32d [c:\users\gary_\rstudio\dependencies\windows\install-boost\boost_1_69_0\rstudio\libs\thread\src\win32\thread.cpp @ 678] 
03 0000005f`615f9d80 00007ff7`f30896d1 rsession!rstudio_boost::detail::basic_cv_list_entry::interruptible_wait(struct rstudio_boost::detail::mono_platform_timepoint * timeout = 0x0000005f`615f9ed8)+0x3d [c:\users\jmcphers\git\rstudio\dependencies\windows\boost-1.69.0-win-msvc141-debug-static\boost64\include\boost-1_69\boost\thread\win32\condition_variable.hpp @ 96] 
04 0000005f`615f9db0 00007ff7`f308a6c0 rsession!rstudio_boost::detail::basic_condition_variable::do_wait_until<rstudio_boost::unique_lock<rstudio_boost::mutex> >(class rstudio_boost::unique_lock<rstudio_boost::mutex> * lock = 0x0000005f`615f9f28, struct rstudio_boost::detail::mono_platform_timepoint * timeout = 0x0000005f`615f9ed8)+0xe1 [c:\users\jmcphers\git\rstudio\dependencies\windows\boost-1.69.0-win-msvc141-debug-static\boost64\include\boost-1_69\boost\thread\win32\condition_variable.hpp @ 265] 
05 0000005f`615f9e70 00007ff7`f35010dc rsession!rstudio_boost::condition_variable_any::timed_wait<rstudio_boost::unique_lock<rstudio_boost::mutex> >(class rstudio_boost::unique_lock<rstudio_boost::mutex> * m = 0x0000005f`615f9f28, class rstudio_boost::posix_time::ptime * abs_time = 0x0000005f`615f9f58)+0x90 [c:\users\jmcphers\git\rstudio\dependencies\windows\boost-1.69.0-win-msvc141-debug-static\boost64\include\boost-1_69\boost\thread\win32\condition_variable.hpp @ 559] 
06 0000005f`615f9f00 00007ff7`f3500ae4 rsession!rstudio::session::HttpConnectionQueue::waitForConnection(class rstudio_boost::posix_time::time_duration * waitDuration = 0x0000005f`615fa148)+0x9c [c:\users\jmcphers\git\rstudio\src\cpp\session\http\sessionhttpconnectionqueue.cpp @ 118] 
07 0000005f`615fa050 00007ff7`f3297949 rsession!rstudio::session::HttpConnectionQueue::dequeConnection(class rstudio_boost::posix_time::time_duration * waitDuration = 0x0000005f`615fa148)+0x94 [c:\users\jmcphers\git\rstudio\src\cpp\session\http\sessionhttpconnectionqueue.cpp @ 89] 
08 0000005f`615fa0b0 00007ff7`f30e2dd0 rsession!rstudio::session::http_methods::waitForMethod(class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * method = 0x0000005f`615fa688, class rstudio_boost::function<void __cdecl(void)> * initFunction = 0x0000005f`615fa660, class rstudio_boost::function<bool __cdecl(void)> * allowSuspend = 0x0000005f`615fa638, struct rstudio::core::json::JsonRpcRequest * pRequest = 0x0000005f`615fa550)+0x269 [c:\users\jmcphers\git\rstudio\src\cpp\session\sessionhttpmethods.cpp @ 484] 
09 0000005f`615fa4f0 00007ff7`f337f60d rsession!rstudio::session::console_input::rConsoleRead(class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * prompt = 0x0000005f`615fabd8, bool addToHistory = true, struct rstudio::r::session::RConsoleInput * pConsoleInput = 0x0000005f`615fac50)+0x280 [c:\users\jmcphers\git\rstudio\src\cpp\session\sessionconsoleinput.cpp @ 313] 
0a 0000005f`615fa9a0 00007ff7`f3ff1e6c rsession!rstudio_boost::detail::function::function_invoker3<bool (union rstudio_boost::detail::function::function_buffer * function_ptr = 0x00007ff7`f563fa10, class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * a0 = 0x0000005f`615fabd8, bool a1 = true, struct rstudio::r::session::RConsoleInput * a2 = 0x0000005f`615fac50)+0x4d [c:\users\jmcphers\git\rstudio\dependencies\windows\boost-1.69.0-win-msvc141-debug-static\boost64\include\boost-1_69\boost\function\function_template.hpp @ 101] 
0b 0000005f`615fa9e0 00007ff7`f3feb1db rsession!rstudio_boost::function3<bool,std::basic_string<char,std::char_traits<char>,std::allocator<char> > const &,bool,rstudio::r::session::RConsoleInput *>::operator()(class std::basic_string<char,std::char_traits<char>,std::allocator<char> > * a0 = 0x0000005f`615fabd8, bool a1 = true, struct rstudio::r::session::RConsoleInput * a2 = 0x0000005f`615fac50)+0xac [c:\users\jmcphers\git\rstudio\dependencies\windows\boost-1.69.0-win-msvc141-debug-static\boost64\include\boost-1_69\boost\function\function_template.hpp @ 765] 
0c 0000005f`615faa50 00000000`6c825005 rsession!rstudio::r::session::RReadConsole(char * pmt = 0x0000016d`356c36f0 "> ", char * buf = 0x0000005f`615fb01c "DT::datatable(data.frame(x = Sys.Date())).", int buflen = 0n4096, int hist = 0n1)+0x3bb [c:\users\jmcphers\git\rstudio\src\cpp\r\session\rstdcallbacks.cpp @ 317] 
0d 0000005f`615faf90 00000000`6c8254f1 R!Rf_ReplIteration+0x115
0e 0000005f`615faff0 00000000`6c825592 R!Rf_ReplIteration+0x601
0f 0000005f`615fc070 00007ff7`f3fe52ca R!run_Rmainloop+0x52
10 0000005f`615fc0a0 00007ff7`f3fd05d2 rsession!rstudio::r::session::runEmbeddedR(class rstudio::core::FilePath * rHome = 0x0000005f`615fc8d0, class rstudio::core::FilePath * userHome = 0x0000005f`615fdb10, bool quiet = false, bool loadInitFile = true, SA_TYPE defaultSaveAction = SA_SAVEASK (0n5), struct rstudio::r::session::Callbacks * callbacks = 0x0000005f`615fc770, struct rstudio::r::session::InternalCallbacks * pInternal = 0x00007ff7`f563fd28)+0x48a [c:\users\jmcphers\git\rstudio\src\cpp\r\session\rembeddedwin32.cpp @ 198] 
11 0000005f`615fc2e0 00007ff7`f32c55cd rsession!rstudio::r::session::run(struct rstudio::r::session::ROptions * options = 0x0000005f`615fdb10, struct rstudio::r::session::RCallbacks * callbacks = 0x0000005f`615fe450)+0xf42 [c:\users\jmcphers\git\rstudio\src\cpp\r\session\rsession.cpp @ 371] 
12 0000005f`615fcb80 00007ff7`f449ddb4 rsession!main(int argc = 0n9, char ** argv = 0x0000016d`335f43a0)+0x34ed [c:\users\jmcphers\git\rstudio\src\cpp\session\sessionmain.cpp @ 2119] 
13 0000005f`615ff720 00007ff7`f449dc9e rsession!invoke_main(void)+0x34 [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 79] 
14 0000005f`615ff760 00007ff7`f449db5e rsession!__scrt_common_main_seh(void)+0x12e [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
15 0000005f`615ff7d0 00007ff7`f449de49 rsession!__scrt_common_main(void)+0xe [f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331] 
16 0000005f`615ff800 00007ffe`a31f4034 rsession!mainCRTStartup(void)+0x9 [f:\dd\vctools\crt\vcstartup\src\startup\exe_main.cpp @ 17] 
17 0000005f`615ff830 00007ffe`a3c23691 KERNEL32!BaseThreadInitThunk+0x14
18 0000005f`615ff860 00000000`00000000 ntdll!RtlUserThreadStart+0x21

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 1, 2020

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:

http://localhost:13464/session/viewhtml1b20504bf4c/index.html

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.

@makuluvet
Copy link

@makuluvet makuluvet commented May 2, 2020

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)

Hi there, I have a very similar issue with plotly:

  • Windows 10 x64
  • R 4.0.0, RStudio 1.2.5042

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

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 2, 2020

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 DBG(X) X as instructed. With the debugging output enabled, the issue doesn't repro. Turned it back to DBG(X) to disable debugging output--the problem returns. (I did this with a 32-bit binary FWIW)

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 3, 2020

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 CONNECTION_CLOSE) the problem is fixed.

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 3, 2020

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.

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 3, 2020

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 in_process flag that's intended to prevent reentrancy.

This flag is written in process_request, and checked from worker_input_handler.

On non-Windows, this presumably works fine. worker_input_handler calls process_request, which sets the flag before entering into R, which may cause an input handler to be invoked, which may call worker_input_handler, which then notices the flag is set, so it returns early. Fine. (I'm not exactly sure what is supposed to happen to the request in this case...? Never mind that for now.)

On Windows, it's not as simple. worker_input_handler appears to call process_request, but thanks to some macro trickery, it's a totally different process_request implementation that appears earlier in the file, here. This is because worker_input_handler is invoked on a background thread, and (the real) process_request has to run on the main thread. The problem is that now, in_process is being set on the main thread, and read from multiple background threads, randomly causing them to exit worker_input_handler early!

To fix this, you can just #ifndef _WIN32 away the conditional return in worker_input_handler--this is safe, because reentrancy isn't possible with the threaded implementation anyway. With this change, I can't repro the problem at all.

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 3, 2020

Now that I said that... I'm not sure why returning early from worker_input_handler would be such a problem. It's being called in a tight loop, so as soon as in_process returns to 0, these threads should pick up where they left off.

However, if somehow in_process was getting stuck at 1, that would explain why each run pegs the CPU at 100%--it's creating a new thread that's stuck in this tight loop of checking in_process and returning early.

After writing the above, it occurred to me that static int in_process really ought to have volatile. And to my surprise, merely adding volatile fixes the bug as well. Maybe the problem here is not that the code has changed recently, but the compiler behavior has?

@christophGeoHealthCentre

Thank you jcheng5 for pointing me to this threat from #422.

I can completely confirm your observation of
"... 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 ..."

@jmcphers jmcphers self-assigned this May 4, 2020
@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 4, 2020

Maybe the problem here is not that the code has changed recently, but the compiler behavior has?

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.

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 4, 2020

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 browseURL to the location on disk (which works fine). It's only with RStudio that htmlwidgets are served through the local Rhttpd server.

But if you do it using RGui, it reproduces:

  1. Launch any help topic, e.g. ?ls; take note of the URL, in my case http://127.0.0.1:18556/library/base/html/ls.html
  2. Launch a leaflet map or DT; take note of the path, in my case file:///C:/Users/jcheng/AppData/Local/Temp/Rtmp6VsXpH/viewhtml17eccd1f3e/index.html
  3. Combine the two paths to make http://127.0.0.1:18556/session/viewhtml17eccd1f3e/index.html

(No disagreement about serving the file yourselves!)

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented May 4, 2020

Is it worth filing a bug report for R on this?

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 5, 2020

@R-Hannibal
Copy link

@R-Hannibal R-Hannibal commented May 7, 2020

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.

@melkitt
Copy link

@melkitt melkitt commented May 8, 2020

I'm having the same issue currently. What is the fix?

@jmcphers
Copy link
Member

@jmcphers jmcphers commented May 8, 2020

The fix is to download the preview version of RStudio. You can get it here:

https://rstudio.com/products/rstudio/download/preview/

@jcheng5
Copy link
Member

@jcheng5 jcheng5 commented May 12, 2020

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!

@R-Hannibal
Copy link

@R-Hannibal R-Hannibal commented May 19, 2020

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.

@R-Hannibal
Copy link

@R-Hannibal R-Hannibal commented May 19, 2020

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.

@Dmirijs-Ozernovs
Copy link

@Dmirijs-Ozernovs Dmirijs-Ozernovs commented Jan 7, 2021

Hi!
Have the same symptoms (white Viewer pane, CPU 100% load for rsession process) when using functions like knitr::kable or plot_ly. Problem occurs about 80% of the times.

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

@oduilln
Copy link

@oduilln oduilln commented Feb 15, 2022

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:

> sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 18363)

Matrix products: default

locale:
[1] LC_COLLATE=English_Ireland.1252  LC_CTYPE=English_Ireland.1252    LC_MONETARY=English_Ireland.1252
[4] LC_NUMERIC=C                     LC_TIME=English_Ireland.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] mapview_2.10.4.9004  lattice_0.20-44      scales_1.1.1         RColorBrewer_1.1-2   leaflet_2.0.4.1      tmap_3.3-3          
 [7] crosstalk_1.2.0      plotly_4.10.0        sf_1.0-6             forcats_0.5.1        stringr_1.4.0        purrr_0.3.4         
[13] readr_2.1.1          tidyr_1.1.4          tibble_3.1.6         ggplot2_3.3.5        tidyverse_1.3.1      DT_0.20             
[19] shinyWidgets_0.6.3   shinyjs_2.1.0        shinydashboard_0.7.2 dplyr_1.0.7          shiny_1.7.1         

loaded via a namespace (and not attached):
 [1] leafem_0.1.6            colorspace_2.0-2        ellipsis_0.3.2          class_7.3-19            satellite_1.0.4        
 [6] markdown_1.1            base64enc_0.1-3         fs_1.5.2                dichromat_2.0-0         rstudioapi_0.13        
[11] proxy_0.4-26            farver_2.1.0            bit64_4.0.5             fansi_1.0.2             lubridate_1.8.0        
[16] xml2_1.3.3              codetools_0.2-18        cachem_1.0.6            knitr_1.37              jsonlite_1.7.3         
[21] tmaptools_3.1-1         broom_0.7.11            dbplyr_2.1.1            png_0.1-7               compiler_4.1.0         
[26] httr_1.4.2              backports_1.4.1         assertthat_0.2.1        fastmap_1.1.0           lazyeval_0.2.2         
[31] cli_3.1.1               later_1.3.0             leaflet.providers_1.9.0 htmltools_0.5.2         tools_4.1.0            
[36] gtable_0.3.0            glue_1.6.1              Rcpp_1.0.8              cellranger_1.1.0        jquerylib_0.1.4        
[41] raster_3.5-15           vctrs_0.3.8             leafsync_0.1.0          lwgeom_0.2-8            xfun_0.29              
[46] rvest_1.0.2             mime_0.12               lifecycle_1.0.1         XML_3.99-0.8            terra_1.5-17           
[51] vroom_1.5.7             hms_1.1.1               promises_1.2.0.1        parallel_4.1.0          yaml_2.2.2             
[56] sass_0.4.0              stringi_1.7.6           highr_0.9               e1071_1.7-9             rlang_1.0.1            
[61] pkgconfig_2.0.3         evaluate_0.14           htmlwidgets_1.5.4       bit_4.0.4               tidyselect_1.1.1       
[66] magrittr_2.0.2          R6_2.5.1                generics_0.1.1          DBI_1.1.2               pillar_1.7.0           
[71] haven_2.4.3             withr_2.4.3             units_0.8-0             stars_0.5-5             abind_1.4-5            
[76] sp_1.4-6                modelr_0.1.8            crayon_1.4.2            KernSmooth_2.23-20      utf8_1.2.2             
[81] tzdb_0.2.0              grid_4.1.0              readxl_1.3.1            data.table_1.14.2       reprex_2.0.1           
[86] digest_0.6.29           classInt_0.4-3          webshot_0.5.2           xtable_1.8-4            httpuv_1.6.5           
[91] stats4_4.1.0            munsell_0.5.0           viridisLite_0.4.0       bslib_0.3.1

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

leaflet::leaflet() %>% leaflet::addTiles()

but I think it might be specific to some of my versions. Is there something I should try and update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.