Firefox integration?

Hi all,

I read a post from June that said LL is working on this, anyone know the status?

Check outthis post which refers to Cory's latest blog entry about it.

Is "orgasmic" a stage of development?

The code bounty is definately cool. Let's hope someone is up to the challenge.

You misunderstand...

Screw the bounty. If they integrated uBrowser as is, I would have to do an about face on everything I've said to date about Linden Lab!

Heh, I'm ready for it as is too. I don't need plugins, new windows or feedback dialogs.

Dynamically rendered textures and text would rock!

AND JAVASCRIPT! JavaScript -- XmlHttpRequest specifically -- works too. We can integrate so much! So much!

Cookies seem to be hinky, but again, I can live with it as is.

OMG. This is going to revolutionize SL.

P2

Err...I'm against javascript in SL... any kind of scripting excepted builted-in LSL in fact. I don't want any more flaw as it already is in the internet.

I'm with Nargas. Combining HTML's rendering hoggyness with SL's rendering hoggyness? Ick.

How do you mean? You mean in memory? CPU cycles?

CPU cycles. Both. Firefox is a pretty big browser to begin with, but in any browser web pages can chew up huge amounts of memory doing pretty much nothing (think LSL written by bad coders with no memory limits and embeddable textures), and the performance of HTML/Javascript-based applets is often horrible. Some bulletin boards chew up so much CPU time in Firefox just tracking what I type and rendering it as a "preview" I can't use it on older machines.

When I go into SL on my Mac mini, I quit Firefox first.

If you've got HTML on a prim, with that getting rendered and updated in anything like real time, it's going to cut into your frame rate... and it won't matter HOW good your video card is this time.

Actually Firefox is pretty light as far as browsers go, at least I notice it's more responsive and has a smaller memory footprint than other browsers I could name for Windows. But you're right, real time updates on a prim browser will really hurt your frame rate. I'm willing to bet it's only semi-real time with texture updates every few seconds. That is more realistic, and it would allow you to browse most websites out there. Flash would be right out, and most applets probably wouldn't work at all either. I'd also agree that window altering javascript, vbscript, or CSS should not be permitted on the grounds that not only would it be impractical due to the semi-real time nature, it would in many cases trump LSL for features. Dynamic content javascripts though (so long as they won't change the content after the page has been rendered), and PHP, I fully endorse because that's the whole point of having a web page in SL.

Lynx for SL would be awesome though, nothing beats lynx for speed and versitility. ^.^;

Even non-real-time updates: it's not copying the texture into the view that's the problem, it's rendering the view in the window. It's not a big problem with the browser in a separate window because when I'm looking at the window (in Camino, actually, but it's the gecko rendering engine and somewhat less CPU-intensive because it's not using XML and scripts to render the user interface as well as the browser) I don't care about my frame rate in the partially obscured SL window... but otherwise...

What I'd really like to see is for SL to act like a window manager, with arbitrary applications rendered onto prims (under the user's control, SL would just provide a way for you to specify the application *). This is trivial on UNIX (X11 is designed for it) and shoudln't be too hard on OS X (because every window is an OpenGL texture or rendered via OpenGL already) but may be tougher on Windows. There's a lot of applications I use that are pretty lightweight that I'd love to bring into the SL world and stick in my HUD.

We already know they're working on Flash.

* Something like:

[x] Replace texture: [                                    ]
    With application: [xterm -e lynx                                                 ]

One of the main reasons I think HTML in SL will be cool is because I want to script GUIs on HUDs in ways that are not possible today. Javascript, especially with the canvas tag, will be useful for this. Still, maybe there are other ways that would be better.

Maybe on windows it could be done by including something like a local VNC server and client with SL, where the client would render output to OpenGL. I'd still want HTML in SL though, because local applications won't be able to interact with LSL.

Something like... but not actually. VNC only reflects the displayed screen. I think OpenGL might keep you from having an infinite view of the SL window inside the SL window inside the SL window in a recursive tunnel, but it's an amusing thought.

Neither will HTML-in-a-prim, as I understand it.

Yeah I'm not sure if there are any existing software that is really suitable to use so LL would probably have to make their own vnc-like protocol or something.

Well, what I meant is you will be able to change the HTML from LSL with llSetPrimURL and llRefreshPrimURL. This means you can use prim buttons to change what will be displayed on the prims and thus use HTML to make GUIs. As I understand it, it will be possible to read the HTML from a notecard, even without that ability it would just be a bit slower.

The addition of forms though via HTML would mean quite a bit to game makers as a more dynamic means of displaying stats as well as a way to safely store stats out of the SL world in case of sim lag or crashes. It also means interface updates without having to redistribute prims and scripts, just change your web page.

I still feel doing Flash and other real time updates are a "Very Bad Idea" (tm) that will horribly rend frame rates to shreds.