[BUG] Forward slash is changed to %2F in link

[jenssss]

When inserting a link using TapTool and OpenURL, formatting with a @link type string, any forward slash character is converted to %2F, making the link broken. I found this behaviour in Bokeh 2.3.0 and 2.3.1, but not in 2.2.3, where the forward slashes are correctly included in the link.

I'm using python 3.9.4 (from conda) on Ubuntu 20.04.2 LTS, with notebook 6.3.0, tested in both firefox 87.0 and chromium 90.0.4430.72.

Below is an MWE, adopted from the docs

from bokeh.models import ColumnDataSource, OpenURL, TapTool
from bokeh.plotting import figure, output_file, show

output_file("openurl.html")

p = figure(plot_width=400, plot_height=400,
           tools="tap", title="Click the Dots")

source = ColumnDataSource(data=dict(
    x=[1, 2],
    y=[2, 5],
    link=["en/latest/",
          "en/latest/docs/reference/models/callbacks.html?highlight=openurl#bokeh.models.callbacks.OpenURL", 
          ]
    ))

p.circle('x', 'y', size=20, source=source)

url = "https://docs.bokeh.org/@link"
taptool = p.select(type=TapTool)
taptool.callback = OpenURL(url=url)

show(p)

When run in bokeh 2.3.0 or 2.3.1, upon clicking the dot at (x=1, y=2) ,the browser opens https://docs.bokeh.org/en%2Flatest%2F, rather than https://docs.bokeh.org/en/latest/ which is opened when using bokeh 2.2.3.

[erip]

I can confirm that this happens even without prefixed '/'.

[bryevdv]

Fixing this is probably a good opportunity to split up replace_placeholders which is doing far too many things at once: replacing CDS column placeholders, safe escaping, applying a formatter, and optionally creating dom elements (!?).

This callback only needs the first (replacing placeholders) but the only way to get that now would be to tack on "{safe}" to the end of the URL format string an that is too hacky even for me.

[bryevdv]

So the assumption Bokeh is making is that the CDS data item is at most a single URL component, i.e. one part in between two slashes. Or put another way: the CDS data item would not itself have any URL slashes as part of the data, only the format string would. You can see what we had in mind in the official docs example:

url = "http://www.html-color-names.com/@color.php" 

Under this assumption, encodeURIComponent is reasonably called.

But what I only just now appreciated is that the CDS data item here has URL slashes directly inside it. So calling encodeURIComponent breaks things. I think we have no option but to make this explicitly configurable via a flag, and in order to maintain the most compat, I think it has to default to off.

[bryevdv]

OK looking even further, the issue is that previous to #10606 our local util function escape was called. After #10606 it was switched to encodeURIComponent, but the two functions do not behave identically (escape does not replace slashes).

So I this there are two options. Instead of passing encodeURIComponent as the encoder, the OpenURL could pass either

• the local escape util function (should be identical to before), or
• encodeURI which escapes fewer things (i.e does not escape slashes)

I think I am include to try first with encodeURI unless you have different thoughts @mattpap It particular it seems as though encodeURI will handle correctly the case where the CDS data is simply entire, complete URLs for every item.

[mattpap]

encodeURI which escapes fewer things (i.e does not escape slashes)

I think this should be used. In fact it may have been my intention all along.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.