On 2/14/13 5:33 PM, Brian Anderson wrote:
* FFI stack switching - https://github.com/mozilla/servo/issues/278
* FFI virtual calls - https://github.com/mozilla/servo/issues/278
* DOM representation - https://github.com/mozilla/servo/issues/280
* string representation - https://github.com/mozilla/s
On 02/13/2013 07:55 PM, Boris Zbarsky wrote:
On 2/13/13 10:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
I haven't actually created a DOM-related milestone yet because we
haven't come up with a goal that I'm satisfied with ("create working
dom
bindings" is vague). Thin
On 2/13/13 11:19 PM, Patrick Walton wrote:
Servo now ships a known-working version of Rust, so it should be easier
to build.
OK. I've spent about 3 hours so far on that today. So far there were
two build system bugs that had to get fixed just so that I could get out
of configure, a non-buil
On Thu, Feb 14, 2013 at 10:49 PM, Brian Smith wrote:
> For example, Rust can't, in general, stop you from writing "if (!x)" instead
> of "if (x)" like I did in a recent NSS bug.
Depending on what 'x' is and how it was obtained it's possible it
could be stopped. If it's a null pointer check for e
On Thu, Feb 14, 2013 at 10:49 PM, Brian Smith wrote:
> 3. Will that thing support Flash or any other plugins?
>
Definitely not.
I think there is no doubt that Rust on its own brings a lot of security
> advantages to a browser-like thing based on Servo. But, as the design
> document notes, ther
Robert O'Callahan wrote:
> I thought we were going to rely on Rust's
> isolation mechanisms for this kind of finer-grained isolation. I
> thought that was a big part of the point of introducing Rust in the
> first place
Let's make the assumption that some future web browser-like thing, intended f
On Thu, Feb 14, 2013 at 7:19 PM, Luke Wagner wrote:
> > Eventually I can imagine writing the JIT in Rust and using some kind of
> certified
> > compilation to guard against compiler bugs.
>
> I haven't really followed this topic; do you really think this would be a
> feasible approach to a produc
On 2/13/13 11:11 PM, Boris Zbarsky wrote:
Only sets on clean nodes are slow, right? Once you've set something,
you just keep writing to the already-allocated bit.
Right.
Patrick
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.m
On 2/14/13 1:52 AM, Patrick Walton wrote:
Currently, floats aren't really on our priority list; we want them to be
done, but other things are higher priority. For example, the scheduler
rewrite. :)
OK, good. That was non-obvious from the mail that started this thread. ;)
This has the proble
On 2/13/13 10:06 PM, Boris Zbarsky wrote:
That sounds like it should be fast enough, yes. We should verify that
it actually is in practice. Which to me suggests that the scheduler
rewrite is a higher priority than, say, floats. At least if they're
both gated on brson. ;) Do we have any ETA o
> Eventually I can imagine writing the JIT in Rust and using some kind of
> certified
> compilation to guard against compiler bugs.
I haven't really followed this topic; do you really think this would be a
feasible approach to a production JS engine? I appreciate that we'd only have
to certify
On 2/13/13 9:43 PM, Robert O'Callahan wrote:
(Of course a big sandbox around the entire browser, or independent browsing
contexts, could still be useful as a second line of defense to prevent the
system from being persistently corrupted in case of a Rust exploit.)
That's exactly the purpose. Mo
On 2/13/13 11:19 PM, Patrick Walton wrote:
Servo now ships a known-working version of Rust, so it should be easier
to build.
Ah, excellent. I should try again!
Fixing this will require the
scheduler rewrite that brson is currently working on. As per the current
plan for the rewrite, content
On Thu, Feb 14, 2013 at 6:51 PM, Luke Wagner wrote:
> The JS jit will be a major hole in this software isolation scheme, even if
> SpiderMonkey is rewritten in Rust. Furthermore, it doesn't seem like we
> can fix this by putting the JS engine in its own process for all the
> performance reasons
> I thought we were going to rely on Rust's
> isolation mechanisms for this kind of finer-grained isolation.
The JS jit will be a major hole in this software isolation scheme, even if
SpiderMonkey is rewritten in Rust. Furthermore, it doesn't seem like we can
fix this by putting the JS engine i
Sounds good. Just one comment:
On Thu, Feb 14, 2013 at 6:18 PM, Patrick Walton wrote:
> (1) The DOM representation needs to be made into a Rust struct, using the
> unsafe code scheme I alluded to in my reply to Boris.
>
I'm pretty sure you already know this, but --- making the DOM and layout
im
On Thu, Feb 14, 2013 at 6:27 PM, Brian Smith wrote:
> Sandboxing affects the design and implementation of networking, iframes,
> form submission, cross window communication (window.location.href,
> window.history.*, window.postMessage(), etc.), navigation (e.g. clicking on
> a link to navigate to
Robert O'Callahan wrote:
> I also think that sandboxing the engine is not interesting. Assuming
> you're talking about OS-level process sandboxing, there's no risk
> there; we know browser engines can be sandboxed that way.
Sandboxing affects the design and implementation of networking, iframes, f
On 2/13/13 7:25 PM, Robert O'Callahan wrote:
I also think that sandboxing the engine is not interesting. Assuming you're
talking about OS-level process sandboxing, there's no risk there; we know
browser engines can be sandboxed that way.
I don't plan to spend time on the OS-specific parts of th
On 2/13/13 7:23 PM, Robert O'Callahan wrote:
I think it's critical to examine the performance of Servo DOM+layout at its
most vulnerable, which I think is when JS is synchronously pounding on it.
A couple of microbenchmarks spring to mind:
1) DOM bindings performance for simple DOM operations, e.
On 2/13/13 7:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
During a lunch discussion today we decided that we have three areas that
we care most about this year: layout, crow, and dom bindings.
We still need to make basic measurements of round-trip times through our
DOM
On Thu, Feb 14, 2013 at 4:23 PM, Robert O'Callahan wrote:
> 2) Harder: performance of synchronous layout, e.g.
> for (var i = 0; i < 10; ++i) {
> element.setAttribute("style", "width:" + i + "px");
> element.getBoundingClientRect().width;
> }
>
All that matters here is that you mo
On 2/13/13 10:16 PM, Boris Zbarsky wrote:
On 2/13/13 9:47 PM, Brian Anderson wrote:
I haven't actually created a DOM-related milestone yet because we
haven't come up with a goal that I'm satisfied with ("create working dom
bindings" is vague). Things we've considered as short-term bindings
goals
On Thu, Feb 14, 2013 at 3:48 PM, Brian Anderson wrote:
> * Milestone 2: Create a frontend that sandboxes the engine and routes
> several important UI events (scroll, mouse, resize)
>
I also think that sandboxing the engine is not interesting. Assuming you're
talking about OS-level process sandbox
On Thu, Feb 14, 2013 at 3:48 PM, Brian Anderson wrote:
> I haven't actually created a DOM-related milestone yet because we haven't
> come up with a goal that I'm satisfied with ("create working dom bindings"
> is vague). Things we've considered as short-term bindings goals are canvas
> and WebGL.
On 2/13/13 9:47 PM, Brian Anderson wrote:
During a lunch discussion today we decided that we have three areas that
we care most about this year: layout, crow, and dom bindings.
We still need to make basic measurements of round-trip times through our
DOM to layout and back on a sync layout flus
Greetings.
We're in a bit of a lull in servo development right now, with Patrick
and I mostly doing the minimal maintenance to keep it building.
Fortunately Josh and Simon are both hacking away at features, DOM
bindings and CSS parsing, respectively, so we're still moving forward.
Over the co
27 matches
Mail list logo
