Help Embed Firefox in SL

Check out Cory's latest blog entry.

"There are only a few remaining show stoppers, but they're tricky. The biggest is the fact that we don't properly handle control inputs in plugins, like Flash. So, think you can fix it? If you do, I'll give you aprivate island in Second Life, including both the up-front cost and the monthly dues for one year. Note that the solution must work on Windows, Mac, and Linux -- or, if we've fixed it on one or more platforms, on the platforms that are still unsolved. I'll post updates here as we move along. For two other bugs -- creating new windows and feedback dialogs -- I'll reward the intrepid coder behind the solution with the ability to create a new last name within Second Life"

Go Cory, go Cory, go Cory

Holy. Crap. Nothing in SL has made my draw drop lately. This has.

I'll poke around at the code, but I know it's out of my league, but who knows? Maybe I'll get lucky.

Great job, Cory!

Goddamn. Now there is an offer.

UBrowser is lookin good. Great to see this project moving along. Not surprised to hear that plugins are causing probs. Not that I've ever tried to do anything quite like this but as a programmer I can understand how much of a pain these type of pluggable systems can be. I was actually under the impression plugins weren't going to be usable to begin with anyway. Wouldn't it make more sense to leave that kind of thing out in the initial implentation so we can see how the basic browser idea is gonna go inside SL first?

Hmm so far, I've seen how rewards go SL, I'm not biting on this one.

Brilliant! The bounty, ubrowser, et all.

Impressive. I run Linux/XP native and have a friend with OS X. If I had the time to commit to something like this, I would definitely consider it.

I don't know enough C/C++ to be useful, but if anyone needs a beta tester, I can help with Windows XP and 2000 on a desktop and a laptop.

In some ways this can be seen as LL's first attempt at letting the community contribute code for the SL client. It's a pretty good oppurtunity to prove to LL that they should open up more of their software and let us help out.

If this is successful then who know, maybe there is an OpenGL version of Jabber bounty next!

Dude! uBrowser has XmlHttpRequest, we can build out own Jabber clients now -- well, technically we can now, but hitting the XML-RPC gateway every few seconds seems an expensive way to chat externally.

Took a look at the code. Nifty stuff!


Though I wonder if I should laugh or cry that the main source file (32kb) is shorter than my Blender tool (52.24kb so far...)

Might have a look this weekend if work doesn't totally kick my arse -- been a few months since I got my teeth into something solid ;P

I don't NEED flash or any other stupid plugin, just release the damn thing already!

Yeah. I don't get it either. Just report 'not supported' and be done with it. If you're trying to get the whole web working on a prim, forget it! It'll never happen.

Gonna include stuff like my networked DirectX driven virtual world-in-a-browser that works from a simple plugin, are you? Whilst I'd REALLY like to see that on a prim, I really don't think it's necessary to hold up deployment cuz a few things don't work yet.

I mean, ffs... look at streaming video. Virtually nothing bloody works, including half the supposed Quicktime supported stuff. It's a good job you didn't hold that back til it supported everything possible!

Great idea Satchmo...if you can make a group...I'll do what I can to find you coders willing to participate.

I even suggest you make this a proposal of some form to raise awareness perhaps.

- Calix

Strange day. I actually have to agree with you, Kris

Interaction with Flash would be really nice, though, but it can surely wait, for the next version of the SL browser or so.

Holy Crap your right!!! The biggest advantage over XML-RPC besides perfomance is a JS enabled HUD that finally gives you a modern GUI to IM.



I'm pretty busy until Sunday, but if nothing happens by then, I'll be happy to organize some sort of group of hackers to collaborate on this thing.

Maybe we can even raise $Linden cash bounty from the community since this browser is something many of us want.

Nice to see some progress!
Damn. I wish I could code.

OMG. It's so exciting!

Questions (probably to early to ask, but):

Cory, will the functionality be limited to owners of parcels, like streaming?

If so, will the browser be limited to one instance on a parcel, like streaming?

Willl an html page display to anyone in range, like a normal texture, or will users have to PLAY the page to start, like streaming video?

I have a video arcade where I'd like to display multiple instances automatically, as attract modes for arcade games. Id like multiple customers to be able to play different games simulteanously on different cabinets.

Great work! I Cant wait! Did I mention, OMG!

Release it without plugin support! We already have support for Flash through video streaming, since Quicktime supports flash functionality. I'd say shoot for the basics, THEN go for the bells and whistles.

This is a really cool step and GREAT news.

I'm certain that it will work just like streaming video in that each person viewing the web on a prim will actually just be viewing an exclusive instance of the browser embedded in their SL client. All rendering/refreshing/interactivity within that browser not be visible by others.

As for limiting it to parcel owners and limiting it to a single browser per parcel remains to be seen.

Hopefully you'll also be able to 'play' certain pages similar to what you can do with QT.

Eg: llShowPage(key k, string url)

This way we will be able to synchronize (somewhat) if we so desire.

A global function, llShowAllPage(string url) which sets the URL for everyone on the parcel would be desireable as well.

Mmmm. Please, PLEAZE let us use this both parcel-based and independent!

I wish I knew Firefox more

As far as I can tell, the beastie is liable to be in the function inside embeddedBrowser that "fakes" a mouse click to the underlying Firefox (embeddedBrowser:endMozillaMouseEvent). It has to do a fair amount of data digging to get to the object that it actually sends the event to. It actually sends it by calling dispatchEvent on the Mozilla view manager, but unfortunately, the event struct has to have a widget parameter inside to tell it where to send it to. The LL code digs down to the "root view" and gets its "widget" value, but I'm guessing that in the case of a plugin, that isn't necessarily the right one.

Now, it would appear you can go in "higher" than this: instead of viewManager->DispatchEvent(&mouseEvent,&status), you can (I think) do docShell->getPresShell()->HandleEvent(&rootView,&mouseEvent,&status)?

Just some guessing, in case it might happen to help someone - I have no clue how to get it to even build, really