[sldev] [VWR] llmozlib and xulrunner

[Rob Lanphier]

Hi all,

I'd like to follow up on Callum's responses here.

On 3/7/08 10:16 AM, Callum Prentice wrote:
 > [Robin wrote:]
> > With all these changes to mozilla, are any of these being submitted to
> > the mozilla project to improve the browser in embedded environments?
> > so may be one day mozilla xulrunner will do the things we require of
> > it?
>
> There was some (brief) talk about this but it never happened. Now that 
> FF3/Gecko 1.9 is approaching release, our changes, based around 
> FF2/Gecko 1.8.1 have little chance of being accepted.

I believe Mozilla doesn't require contributor agreements, and all of our 
code should be compatibly licensed.  So, if anyone wants to submit 
changes on our behalf, please do.  I'm happy to help if it becomes an 
issue that someone from Linden Lab needs to get involved or that there's 
some licensing snafu that's a roadblock.

As Callum said, the current set of changes might be water under the 
bridge, though.  However, there's nothing policy-wise from Linden Lab 
that would block this (or at least, that I'm aware of).
> > Is the mozilla's embedding API absolutely not up to what is required
> > of it? So there is no alternative but to patch the mozilla code? I
> > remember there are issues with native controls being displayed
> > incorrectly and it seems that a whole bunch of embedding call backs
> > need to be added to mozilla to do some basic things? So is mozilla
> > just broken, or are we trying to do something with it it was never
> > designed to do?
>
> The Mozilla embedding API we are using isn't, in its unpatched state, 
> able to do what we need. Opening a browser pane in a native OS window 
> and  make it interactive is straightforward. In our case, rendering 
> off  screen, making everything work under these conditions and fixing 
> the things that break is more involved.
>
> The story might well be different with FF3 - I haven't had chance to 
> look yet. I know that the components we use internally are 
> substantially  different so there will be significant work involved 
> but it's possible  the end result will more straightforward.

Any volunteers to take a look at this?  While we're not going to have 
time to look at this right away, we're really interested.  If anyone is 
worried about duplication of effort, maybe file something in JIRA and 
let everyone know (esp. Callum and I).  I'm guessing that if there's a 
task that we're watching that's getting periodic updates, we won't be as 
likely to step on one another's toes.

> > Webkit keeps being mentioned as an alternative. Is there any real
> > interest in this at all? Any one know if it is capable of achieving
> > the same *without* being patched?
>
> People here are indeed looking at Webkit and there is significant 
> interest. The discussions I've seen suggest that we will try to get 
> the functionality we need into the WK trunk rather than having to 
> maintain patches,

Things look promising for a very workable API to make it into Webkit.  See:
http://bugs.webkit.org/show_bug.cgi?id=16885

> I'm in the process of moving LLMozLib2 development out of our internal 
> SVN repo altogether and into the external one. Hopefully, that will 
> make  things better for all of us. I'm currently 'grid monkey' for a 
> week so I've some distractions to deal with but I'm hoping to have it 
> set up by the end of next week at the latest. I'll post here of course 
> when it's done.
>
> Thanks for preserving with this Robin and I'm sorry it's been so painful.
Indeed, thanks!

Rob

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080307/650d930d/signature-0001.pgp