Offer templates sometimes wrap weirdly

[paulproteus]

This is what I see in davros's offer template:

To avoid this problem, maybe template embedders ought to:

• Set the min height of the IFRAME to 40 higher than they think, so the scrollbar always fits
• Adjust the CSS of the offer template so it doesn't scroll
• ?

Once we know what to tell them, then I can change the docs so we actually tell them that. For now, I'm not sure what to suggest so for now I just wanted to file this.

P.S. I got those API tokens a few hours ago, so presumably they are revoked.

[mnutt]

I can make the iframe taller so it doesn't overlap.

Oftentimes I think the desired outcome is actually something very similar to an <input> field, it may be possible to signal to the iframe that you want it to look like a text input field and have the inner css set such that it's all on one line but scrolls in a reasonable way. Maybe even a copy-to-clipboard link on one side using http://caniuse.com/#feat=clipboard ?

[zarvox]

These all sound like reasonable options to pass to the shell. I'd happily review patches to improve styling options for offer-templates - perhaps these all become part of a presentation subobject of the initial renderTemplate object that the app postMessages to the shell? This would also allow us to throw in type: "qrcode".

I could see some additional whitelisted styles that you could pass to the type: "text" renderer - we have to make sure you don't use any CSS that could leak bits by making external requests, but you could specify some things like font-size for layout, color, background-color, and maybe some other basic styles for better integration.

@ndarilek also mentioned that it would be convenient to have this render as a <textarea>, but I hit issues with unintentional wrapping in the textarea, where you might prefer scrolling (so you can know the dimensions of the thing you're trying to frame).

Tricky.

[ndarilek]

Actually, I think the textarea bit is more something you'd pass as your template, something like: ``` var template = "Use the following command to connect:<br/><textarea>cmdline-client $API_HOST $API_TOKEN</textarea>"; ``` With that set up, I could very easily copy-paste the commands, but that isn't something I'd want done universally. I think it's what Github does when you set up a new repo, for instance, but I'd want a link rendered as an `<a/>` so I could tab to it, right-click and use "Copy link location," etc. So for Gitlab I'd like to see all the copy-pastable Git commands in a `<textarea/>` if possible, but not the entire template.

[zarvox]

@ndarilek The trouble with that is that it breaks confinement. If you can specify arbitrary HTML, you can also specify an onclick, onload, or onerror attribute on that <textarea> or any other field that is a Javascript function, and now you're executing code in the shell's origin, which would let any app to take over your account. There's probably similar attributes you could put on an <a> to cause code-execution. So we have to limit what can be rendered, which is why it's just plaintext at the moment.

If you could put just the textarea's contents into the offer template, then would a presentation: {type: "textarea"} option make you happy?

Similarly, a presentation: {type: "link"} seems like it should be possible too, though there might be some confinement-related caveats. You guys are giving me lots of good ideas. :)

[ndarilek]

The catch is that I'd like for only parts to be in a textarea, not the entire thing though as that defeats the point. I like it for things you'd type into a command line, but not for the entire content. Given that it isn't a super easy thing to implement, I'd be OK with punting it for now. I also wonder if there is a battle-tested HTML sanitization API that would let you whitelist, say, <a/> and <textarea/> but nothing else. I'd never advocate shoving arbitrary HTML into that field. :)

[mnutt]

@ndarilek would it be possible to make the offer-template iframe only the textarea, just put your other content outside the iframe? Or are there offers-template variables that need to go outside?

(one challenge is that if you add two offers-templates to a page, you get two different api keys)

[ndarilek]

See https://github.com/sandstorm-io/sandstorm. Look below the header
"HTTPS clone URL".

The URL is included in a <textarea/>.

If I as a screen reader user hit tab, I can land in the field. I can
then hit ctrl-a, ctrl-c, switch into this issue, press ctrl-v and get
"https://github.com/sandstorm-io/sandstorm.git".

If we put the entire template into a <textarea/>, we lose that ease of
focusing and copying the actionable text. It only really makes sense for
the URL, API token, Git/HG commands, etc. but exactly what it makes
sense for varies from instance to instance.

I think the best solution would be a whitelisted set of HTML tags, maybe
<a/> <b/> <i/> <textarea/>, and some sort of Sandstorm human interface
guidelines that recommend making the actionable item either an if
it's a link, or a <textarea/> if it's a long set of commands. That's
probably the best and most flexible way. If that's too complicated to
implement at the moment, then it's probably best to delay it until
later. It isn't a show-stopper, just a nice-to-have.

Thanks.

[zarvox]

Hmmm. Here's an idea to solve the two-different-API-keys problem (though it involves a longer cascading chain of postMessage calls):

renderTemplate could also pass a String reuseTokenFrom with the uri returned by a previous renderTemplate RPC. The shell could then look in sessionStorage for that token (assuming it's still present) and reuse that apiToken value rather than generating a new one. This option would ignore the other petname/roleAssignment/forSharing arguments as well.

This would still only work with sessionStorage, so you wouldn't be able to reuse this across sessions or for different users, but maybe this could solve the oddity in Davros where you wind up generating two distinct API tokens on the same page to connect the desktop sync client.

[zarvox]

@ndarilek It sound like you and @mnutt are in agreement - the textarea should only include the text that you actually want to copy. I think you can accomplish that with the addition of an option that makes the offer template render just the copyable text inside <textarea> and </textarea> instead of <pre> and </pre>.

Is there an issue with tab-focus and iframes that makes it harder to tab to reach/identify a <textarea> inside the iframe? Maybe the app needs to put a tabindex on the iframe, or the textarea offer template renderer should put an autofocus on the textarea? I feel like I'm missing something here.

[ndarilek]

I don't think you'd need to do anything for the textarea. It should get a tabindex by default. I'd also not autofocus it as it isn't likely to be of interest every single time someone hits the grain.