Open bwaismeyer opened 9 years ago
Again, sorry for the lack of responsiveness. I am not getting a behavior you describe when running your example in firefox or chrome. It may be something that has sorted itself out with the newer versions of shiny. Please let me know if you are still having problems and I will try to look into it further.
Confirming that I am no longer see the problem as I described it above. It seems that something was done to remove accidental namespace assignment (at least in these cases).
New issue: The popovers for the sliders aren't working correctly: the V3 popover-on-click is showing up at the top left of the input range and the V4 popover-on-hover isn't visible if it's activating at all.
However, this issue occurs for both versions my code above (i.e., it doesn't seem namespace related). I haven't dug into this code in a while, so it's very possible I would just need to tweak some stuff to make the slider popovers function correctly.
Sorry, Eric, I appear to be on a quest to discover all the popover bugs.
If I assign a popover to an element and the name of that element partially overlaps with an active feature of another element... crazy stuff happens.
Specifically, observe what happens as you try to trigger the popovers for
x_axis_choice2
,x_axis_choice3
, andx_axis_choice4
. The popovers forx_axis_choice2
andx_axis_choice3
end up actually assigned the first element's second and third radio buttons.x_axis_choice4
does not, presumably because the first element has no fourth radio button.As you might expect, one way to address this is to simply remove the number from the end of the element name (e.g.,
x_axis_choice
instead ofx_axis_choice1
). Here's an example with all the problematic element names removed. The odd behavior is gone.However, I suspect this points to a deeper issue given that users are likely to be unaware of what parts of the shiny namespace should be avoided when naming elements.