json-ld playground compaction permalink mangles string contexts

[RoboPhred]

Not sure where to report this, hopefully someone here can point me to where this belongs.

When compacting a context on the json-ld playground, setting the context to a string url that ends in # and copying the link through the permalink button will create a link that takes you to a corrupt and unusable site. The context contains both error text, and the expected link missing both the # and the ending quote. The context area will be read-only, preventing it from being fixed and breaking the playground entirely.

To reproduce:

1. Open the playground
2. Select the compacted option
3. Enter {} for the JSON-LD input.
4. Enter a string context. I am using "https://www.w3.org/2019/wot/td/v1"
5. Note the context warning me against using a string. Note the compacted version continues to function as expected
6. Create a permalink from this configuration
7. Visit the permalink.

Here is a permalink created from these steps. Note the errors displayed and the inability to edit the context.

This seems to be a new bug, as I have successfully generated links to examples using this same string context many times previously.

Workaround: Use {"@context": "https://www.w3.org/2019/wot/td/v1"}.

[gkellogg]

The problem may be because you're using a quoted URL. Try removing the quotes. This is what I got.

[RoboPhred]

I'm not sure I follow. Removing the quotes results in json-ld not knowing what to make of the context:

Here is the context setting that triggers the bug:

I included the warning here, which claims the value cannot be a string. Despite this, the playground still correctly loads the context from the url, and the error message shown at the top of this post does indicate STRING is an expected value here.

[davidlehn]

This is likely a playground issue and would be better over here: https://github.com/json-ld/json-ld.org/issues.

Was the initial problem trying to put the plain URL in the context textfield? Or putting it in the context URL field above it? In the context URL field, it seems to work (as long as you don't put quotes around it). Hash suffix works too as Gregg noted. The plain URL, quoted or not, in the context content textfield really shouldn't work at all. Probably a fluke that it sort of does something. That invalid type message should be a stronger error.