Talk:LSL Browser HUD

Thoughts

It looks good, though i have a few ideas:

• There should be an address bar even if it is read only (don't want to make spoof attacks possible).
• The window should be user resizable without limitation other then the SL window size.
• It needs to be one or more of these a) minimizable b) tab browsing or c) window roll up (a button that collapses it to a title bar)
• There needs to be a BROWSER_HUD_JAVASCRIPT command that allows the object to manipulate it's Browser HUD. It would look something like [BROWSER_HUD_JAVASCRIPT, string eval].
  • string eval - Would be executed in the Browser Hud window by the eval function.
  • This would allow for a script to manipulate it's Browser Hud without having to bounce the user off a webserver.
  • The user should only be able to eval javascript on approved URL handlers (http & https for starters, more could be added with some hidden pref), we don't want accidental privilege elevation by hijacking about:kitchensink.
• Consider extensions to navigator javascript object so that javascript can access viewer specific informations such as SL location, camera position, user name, etc. Might be useful. Consider adding new events so that javascript can hook them. Imagine a user map HUD that updated with the camera (and didn't rely upon script having to know where the camera was; would be a bandwidth savings).
  • Permissions? Auto-grant?
    • [BROWSER_HUD_PERMISSIONS, integer mask] ?

--Strife Onizuka 22:28, 9 April 2008 (PDT)

My thoughts

This seems like a variant of the HTML Dialog suggestion.

• To make this secure, there must be a URL access method that accesses only the Contents of the prim containing the script. By default, this access method must be the only one available to the HUD.
  • http: and https: must not be allowed without asking the user permission.
  • The user must be able to globally disable http: and https:
• There doesn't need to be any way for LSL to do anything but load the HUD with a new block of HTML.

-- Argent Stonecutter 17:16, 8 May 2008 (PDT)

Sweet idea! To replace current OI HUD, Hope this function officially support multi-language.

-- Nock Forager 23:43, 27 April 2008 (PDT)

Impersonation

I just gots to know what would happen if... <lsl>llMiniBrowserCreate( llGetOwner(), "Sillyness",

   "secondlife:///app/browserhudchat/I'm not a script impersonating the user, no really I'm not!",
   <0,0,0>, 0);</lsl>

--Strife Onizuka 22:38, 9 April 2008 (PDT)

This is the first LSL idea I've seen in a long time that I'm actually excited about. Is there an JIRA open to vote for this?

Better than Alternatives

This implementation would be the wisest choice for the linden devs to spend time on than that stupid llTextBox dialog idea. All the dialogs are already messed up and by adding more of those they are going to tie themselves up into a much bigger tangle of code chaos and waste a lot of important time. The LSL Browser HUD would be incredibly handy, especially the secondlife:// URLs for direct client input is an ingenious idea. The web as it is is an incredibly powerful source of existing flexibility which the lindens should tap into more and more bringing that vital connection to the wider more common form of the internet, the web.

Already they have started to assume this important stance with the browser-on-a-prim feature they have been working and they shouldn't just leave it there but also work this for the 2D interface therefore completely eliminating those big blue annoying dialogs which have interferred with the continuation of development in SL.

These are my 2L$. --Nexii Malthus 17:06, 22 July 2008 (PDT)

my opinions

Yes for resizing, plus there should be a way to define size and position by script (both in page and in LSL), but the X to close should never move out of screen even partially.

And what about one window per av per script? any script could control the browsers of any number of avatars, without destroying windows or loosing permission when doing stuff for another av? (other scripts in the same object could also have their own windows)

Also, a Mute button should be present in the browser window itself too in case the was tricked by the permission request and got a unwanted page displayed afterwards