Outputs in text range media chunks do not work

[garethbowen]

Expected Behaviour

It should be possible to set the value of a media chunk based on a calculation. For example in the xlsx setting the image column to ${myimg}.

Observed Behaviour

Instead the form fails to load with an error, similar to "URL constructor: is not a valid URL."

Reproduction Steps

Form (XML or XLSX file):

<?xml version="1.0"?>
<h:html xmlns="http://www.w3.org/2002/xforms"
  xmlns:h="http://www.w3.org/1999/xhtml"
  xmlns:ev="http://www.w3.org/2001/xml-events"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:jr="http://openrosa.org/javarosa"
  xmlns:orx="http://openrosa.org/xforms"
  xmlns:odk="http://www.opendatakit.org/xforms">
  <h:head>
    <h:title>images-choice</h:title>
    <model odk:xforms-version="1.0.0">
      <itext>
        <translation lang="default" default="true()">
          <text id="/data/note:label">
            <value>Reference image</value>
            <value form="image"> jr://images/<output value=" /data/animal "/> </value>
          </text>
        </translation>
      </itext>
      <instance>
        <data id="images-choice" version="20240611120218">
          <animal/>
          <note/>
          <meta>
            <instanceID/>
          </meta>
        </data>
      </instance>
      <instance id="animals">
        <root>
          <item>
            <itextId>animals-0</itextId>
            <name>tiger</name>
            <img>tiger.jpg</img>
          </item>
          <item>
            <itextId>animals-1</itextId>
            <name>camel</name>
            <img>camel.jpg</img>
          </item>
        </root>
      </instance>
      <bind nodeset="/data/animal" type="string"/>
      <bind nodeset="/data/meta/instanceID" type="string" readonly="true()" jr:preload="uid"/>
    </model>
  </h:head>
  <h:body>
    <select1 ref="/data/animal">
      <label>Animal</label>
      <itemset nodeset="instance('animals')/root/item">
        <value ref="img"/>
        <label ref="img"/>
      </itemset>
    </select1>
    <input ref="/data/note">
      <label ref="jr:itext('/data/note:label')"/>
    </input>
  </h:body>
</h:html>

Steps:

1. Load the form.
2. See error

NB: This is the XML produced from xls2xform: <value form="image"> <output value=" /data/animal "/> </value>. If you manually remove the whitespace around the output then you don't get the error but the image doesn't load either.

Screenshots or Videos

Environment

• Browser version:
• OS:
• Web Forms version:

Additional Context

Reported on the forum: https://forum.getodk.org/t/limiting-entity-access-for-app-users-and-data-collectors/54386/23

[garethbowen]

The root issue is that the chunks are split up and processed individually, and when the whitespace is processed it is an invalid URL and blows up. Firstly, we need to not split the chunks up - the output should be evaluated, combined with the rest of the string, and then the URL should be constructed from that. Secondly, I think the invalid URL should be handled more gracefully - if it's computed then it's possible that it's only invalid until certain input is entered or the field is relevant, so loading a broken image would be better than blowing up the whole form.

[garethbowen]

Looking into this more, I'm not sure if this is valid. pyxform handles it perfectly, but I can't find anywhere in the spec or the user manual that mentions anything other than hardcoded values, and I can't get it to work in Enketo either. @lognaturel Is this something you've come across?

[lognaturel]

I think it's likely more of an accidental feature than something that was carefully considered. But yes, I have seen it and Collect supports it.

Are there any downsides to #806? Like does it make resolving any media file slower, for example? If there aren't, I think it would be good to support and explicitly add to the spec.

[garethbowen]

I can't think of any downsides. It only behaves differently if there is a label with media with a nested output - otherwise it should behave and perform just like it does today.

I think it's worth merging - when I wrote that comment I thought it was going to be harder to fix!