Using the HTML floater for complex dialogs.

There have been a number of sugestions for extending the dialogs in SL. Here's a much easier way to get the same functonality, with minimum server-side changes required: An llHTMLWindow request that would, if you had PERMISSION_OPEN_WINDOW (which could be automatically granted to attachments) open a window displaying an HTML page assembled by the script. Almost everything required to implement it is in place:

if (llGetPermissions() & PERMISSION_OPEN_WINDOW) {
  llHTMLWindow(100,100,120,120,
    "<form action='chat:14132'>
      Instead of calling a bunch of dialogs, would you like to be able to
      put up an HTML form like this?<br/>
      <input type=text name=answer value='Hell Yes!'>
      <input type=submit value='Go for it!'>
    </form>");
}

//...

listen(...)
{
   if(channel == 14132)
   {
     list responses = llParseStringToList(msg, ["&"], []);
     integer n = llGetListLength(responses);
     integer i;
     for(i = 0; i < n; i++)
     {
       string s = llList2String(responses, i);
       if(llGetSubString(s,0,6) == "answer=")
         llOwnerSay("You answered "+llUnescapeURL(llGetSubString(s,7,-1));
     }
   }
}

Proposed as VWR-394.

Wow, interesting idea. I like the chat: url idea. I suppose we'd have to parse url-encoded form entries via the script, but I don't actually think that'd be so bad. It should be possible in just a couple of llParseString2List calls and some llUnescapeURL()s.

Like in the above code?

Of course I wouldn't be horrified if they added a couple more calls:

list parameters = llCGI2List(string URI);

Pass it
- "from=Argent%20Stonecutter&to=Lex%20Neva&message=HTML%20FTW!"
And get back a list
- ["from", "Argent Stonecutter", "to", "Lex Neva", "message", "HTML FTW!"]

string URI = llList2CGI(list parameters);

Which would do the opposite operation. WITH proper quoting, so you could use it to pass arbitrary strings around like you can't use llList2CSV and llCSV2List because they didn't implement a safe CSV format.

Just for convenience... I know it's trivial to implement.

Given how vulnerable HTML and related technology implementations seem to be I think this is a bad idea unless it'll only render HTML and no script/Flash/etc.

It should also be subject to the same kill-switch for web profiles, and definitely ask for permission on every view.

Well, it does require permissions before it'll run. In that way, I don't think it's much worse than just visiting a page in your browser. I do think expanding the kill switch to cover things like this (and html on a prim) is necessary, though.

Asking permission isn't that effective at stopping rogue code though.
If you deny every bit of code, you'll be missing out, if you allow every bit you're open to risk. At least with a webpage I can block all javascript until I review what it's doing and then set it to run.

Plain HTML and a way to handle the form submission poses no risk like that as HTML is only for rendering and not running code.
There's also not a great deal of things you could do with javascript in a dialog box that can't be done on the backend with LSL. Rollover buttons aren't exactly essential

rollover buttons can be done (to a degree) with css and xhtml.

I would suggest... an adendum...

Permission DEFINITELY should be ASSUMED given by scripts in attachents... but there should be a land based version of this command.. whereby the land owner can "force" a browser window upon avatars entering their land.

Yes yes, I know... blah all the popups at clubs... But you know what? a lot of pop-up style abilities exist in SL already, and we are not spammed to death on a daily basis.

I'd LOVE to pop into an RP sim, and be greeted by the browser window popping open, with a well crafted, artful website.. explaining their rules, procedures, and whatnot. Imagine that popup having slurls to various locations within the sim. Linked images, etc.. There's a lot of potential for positive use for something like this.

Could we perhaps see a new type of inventory item? the Bookmark?

I can see why you're suggesting it, but personally I'd rather see it integrated with the HUD. Having a window pop up is all well and good for setting options, but for a decent user experience it sucks somewhat.

Although... the option to take take complete control of standard keyboard keys would work too.

Hmm, HTML would certainly be nice, but really ANY way (such as extending the current system with some new constants) to put even rudimentary text-fields onto a dialog would be a huge step forward. It's just chat anyway!

My only concern with HTML is that we only have 16k, a script with a reasonable dialog interface would quickly start eating that up, seeing a need for more scripts to get it to work.

I was thinking in terms of a pretty restricted HTML here... no HTTP-accessed images, frames, embedded content at all, we don't want this to be used to create web bugs. That would automatically mean no flash or other plugins. Scripts, yes, that should probably be disabled at first.

Given this level of restriction, though, there's no point in having things like attachments and other objects you own ask permission.

Given the frequency with which doing fancy things in the HUD broken them (in the new Beta they've broken floating text in HUDs) I'd rather not have them mess around with HUDs any further. New functionality in-world should be available universally, not just in HUDs, and if there's a problem with making it universal there will inevitably be a problem in HUDs as well.

This would be a very limited and specific user interface designed for setting options and interacting with scripts.

Agreed. I've made similar suggestions in the past. I've given up on them. THIS one is easier to implement... they have most of it already done.

It's amazing how little code it takes to produce quite complex HTML forms, once you're forced to actually do it and not use a tool. I can't imagine any sophisticated use of llDialogWithTextAndStuff() being significantly more compact.

For static dialogs, you'd just put them in a notecard.

I do web-design and it's still a pretty hefty-overhead, even if you have implied form-tags, html, body etc which is added in for you. At it's simplest, a modification to llDialog() just needs a DIALOG_TEXT constant or some-such you can put into the buttons list. Magically you now have a text-field on your dialog, if the user fills this in and hits return, then what they entered gets sent. Obviously not very sophisticated, and having buttons as well would confuse things, but it would allow you create a basic web-form with a length one list with a single integer in it

Either way, anything to improve scripted interfaces is a step forward as current dialogues are pretty cumbersome, come to think of it I've thought of another thing that would help, I'll go post it.

Personally, I think it's a very half-way measure and the problems with HUDs are a separate issue and should be addressed as such. You gain: in-place text entry without having to enter a channel; increased response speed from the interface; I think that's it, maybe ease of creation but somebody could (I'd be surprised if someone hasn't) create an intermediary script for it. Obviously I'd like HTML to be extended to all prims, but if locating the position of clicks is an issue, I'd rather see it implemented in HUDs where it forces the prim it's on to set itself to an unrotated cube than forcing an external interface (the browser floater) into the equation. Hell, if it were up to me I'd suggest an entirely new overlay (HUD) system that does away with prims completely and allows client-side scripting (basing on HTML and/or Flash would probably be the way to go).

Thinking about it though, this suggestion should be possible with some modifications to the OS client, shouldn't it? Look for an identifier in the open web page call (I forget what it's called right now) then route it to the floater and return the result in chat.