8 ms·

Another Big Milestone for Servo: Acid2

345 points by dherman 12y ago

camus2 12y ago
When can I expect Servo to be in Firefox instead of the current engine? 2015/2016? do you have a rough idea?
- Narretz 12y ago
  As far as I know there are no short- or even mid-term plans to integrate Servo into Firefox. It's still a research project first. Rust for example doesn't even have a stable API yet.
- kibwen 12y ago
  There are no plans yet to ever integrate Servo directly into Firefox. At the very least Servo will certainly exist as a standalone browser engine (and unlike Gecko, Servo is designed to be embeddable, so it will be an actual alternative to Webkit in that space). The biggest impetus for Servo at the moment is that it's researching the biggest wins to be gained from concurrency and parallelism in browser engines, thereby guiding efforts to tack such things onto Gecko.
  - Symmetry 12y ago
    Well, then I'll hope for a Servo equivalent of Luakit before too long.
- fournm 12y ago
  It may never happen--It's a research engine, not necessarily something that's going to replace Gecko anytime soon.
- mcpherrinm 12y ago
  Servo aims to be "dogfoodable" by the end of the year. It's still an experiment, really, so you won't be able to get anybody to commit to any plans further than that. The design is significantly different from Gecko that I suspect you'd never be able to wedge it into the existing Firefox, but it wouldn't be entirely implausible if a usable browser called Firefox used Servo within 5 years.
- gsnedders 12y ago
  As well as the other replies to this, note there's no plan to implement a lot of the non-standard parts of Gecko that Firefox (and most extensions) rely upon, such as XUL and XBL. Servo is concerned with the web (at least for now) — not replicating Gecko's feature set.
talklittle 12y ago
Previous discussion: https://news.ycombinator.com/item?id=7483729 https://news.ycombinator.com/item?id=7483729
- kibwen 12y ago
  Note that the previous announcement was a bit premature: three weeks ago, on the date of that discussion, Servo was passing Acid2 only on a feature branch. As of two weeks ago the master branch should be passing as well.
acqq 12y ago
Is Servo using GC?
- pcwalton 12y ago
  For the DOM thread only, yes. All layout data structures are not using the garbage collector.
  - steveklabnik 12y ago
    And for those who don't follow Rust closely, it's important that it's "the DOM thread only," as Rust's opt-in GC is on a per-task (thread) basis, so the threads that don't use GC don't even know it's there or running.
    - dbaupp 12y ago
      (Note that Rust doesn't actually have its own GC yet, Servo is just using spidermonkey's JS GC. pcwalton's comment implies it is being used single-threadly though.)
      - metajack 12y ago
        There can be multiple script tasks even within a single page. For example, cross-domain or sandboxed iframes will have each DOM and script in its own task. Also, each of those will have their own layout and rendering tasks.
- metajack 12y ago
  We use Spidermonkey's GC for DOM objects.
schmrz 12y ago
> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Does anyone care to explain how this would work? If you used OpenSSL from Rust you would still be vulnerable to Heartbleed. Or am I missing something?
- jaibot 12y ago
  I believe the implication is that if OpenSSL had been written in Rust, Heartbleed would not have been possible.
  - joshstrange 12y ago
    Which might be true but seems odd to bring up in the blog post. Also they say: >> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed. There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.
    - chimeracoder 12y ago
      > Browsers themselves were not vulnerable to heartbleed, Clients could have been vulnerable to Heartbleed. Feel free to correct me on this, but I believe the only reason they weren't is that Chrome uses OpenSSL compiled without the heartbeat feature, and Firefox uses NSS.
      - azakai 12y ago
        Both Firefox and Chrome uses NSS (although I believe Chrome has a potential plan considering using OpenSSL at some point in the future).
        gsnedders 12y ago
brson 12y ago
Servo is the kind of project that launches a thousand research papers. Some of the early results are staggering and the project is still just getting going. It is a great example of doing serious research to practical ends. Some examples: - firstly, the entire foundation, Rust, is itself an ambitious research project that solves many long-standing problems in the domain. - Servo has, or has plans for, parallelism (combinations of task-, data-parallelism, SIMD, GPU) at every level of the stack. - The entirety of CSS layout (one of the most difficult and important parts of the stack) is already parallelized, and it's fast. - It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture).
- gsnedders 12y ago
  > - It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture). Does Gecko not already do this? Certainly Presto did, and (I believe) Trident does. But to add another bit of research into the mix, and what I think is arguably the most important point: - Builds on all the work around HTML(5) and CSS 2.1, both of which are the best part of a decade of work, both aiming to get browsers actually implementing to specifications, and specifying behaviour in sufficient detail (with minimal undefined behaviour) that a web page cannot easily distinguish two user agents. By actually specifying the web platform as it actually exists, it suddenly makes it far more practical for new browsers to enter the market (compared with the previous hellish situation of the hardest part of developing a browser being reverse-engineering existing browsers with sufficient marketshare that web developers ensure their web pages work in them). If this is shown to be viable, suddenly we have a truly open platform!
  - pcwalton 12y ago
    DOM objects are reference counted in Gecko, and there is a cycle collector to collect JS/C++ cycles. They aren't allocated in the JS heap. WebKit is similar, but without the cycle collector.
ChuckMcM 12y ago
This is awesome, I wonder if there is a more constrained web rendering engine somewhere. Something where rather than 'render everything we've ever seen' is 'render the following html 'standards' correctly' (or at least predictably). I was looking for something like this for a modern day sort of serial terminal thing.
- metajack 12y ago
  We try to support the newer things that are generalizations of the older things. One example of this doing all your list styling with a user agent stylesheet using generated content, instead of hardcoding how list bullets and things work. Also, in some sense, we are doing what you want simply because we don't have a lot of features yet and we prioritize things that are important and things which would have some affect on parallelism or architecture.
- wtracy 12y ago
  If you're not allergic to Java, there's Flying Saucer: http://code.google.com/p/flying-saucer/ http://code.google.com/p/flying-saucer/ http://en.wikipedia.org/wiki/Flying_Saucer_(library) http://en.wikipedia.org/wiki/Flying_Saucer_(library)
  - reitzensteinm 12y ago
    This is one of those only on HN moments. From grandparent's web page: "A long time ago, in a galaxy far far away, I worked for a company called Sun Microsystems. One of the things I did there was to join a renegade band of engineers who were off in Palo Alto working on a technology that nobody within Sun could see any possible use for. That technology was of course Java." http://www.mcmanis.com/chuck/java/ http://www.mcmanis.com/chuck/java/
- richdougherty 12y ago
  Out of interest, what are the reasons you don't want to be able to 'render everything we've ever seen'?
  - 12y ago
sgarlatm 12y ago
I'm curious what Chrome's plans are for the future, in particular related to parallelization. Has anyone seen any articles about that anywhere?
- paulirish 12y ago
  Eric Seidel talks here about some of the ideas in parallelizing things: https://www.youtube.com/watch?v=4Sm-DbIOqiU#t=818 https://www.youtube.com/watch?v=4Sm-DbIOqiU#t=818 And a 2014 Brainstorm thread with similar ideas: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5O...
bithush 12y ago
With the bad press Mozilla has had the past few weeks it is easy for people to forget about some of the awesome things Mozilla are working on such as Rust and Servo. I really like the look of Rust and feel it might be the future native language for high performance applications. It is very exciting!
- nnethercote 12y ago
  Indeed. Brendan's resignation was dismaying and distracting, but we haven't stopped working on stuff. Just after Brendan resigned, I read a comment somewhere to the effect of "I guess that's the end of Firefox OS". Um, no. A major project run by a company of 1,000 employees (and many volunteers) doesn't stop because one person left, even if that person is at the top. Especially when it's progressing well.
macinjosh 12y ago
This is what I see when I run Acid2 in Servo. Perhaps they haven't merged the changes in to the public repo yet. http://cl.ly/image/1b123r220P3u http://cl.ly/image/1b123r220P3u
- pcwalton 12y ago
  Yes, the fix (a submodule update for rust-layers) is blocked on a Rust upgrade which is currently in progress.
modeless 12y ago
I want Rust scripting support in Servo. <script type="text/x-rust" src="foo.rs"> Since Rust is a safe language this should be possible without compromising security, though I don't think anyone's yet attempted to write a JIT compiler for Rust. Has the Servo team considered this as a possibility?
- steveklabnik 12y ago
  I'd imagine that a Mozilla project would just focus on compiling to asm.js...
  - modeless 12y ago
    There are a lot of problems with asm.js: the heap can't be resized after creation, the code size is really large (esp. with things like C++ templates, which are duplicated for each specialization), threads don't work, datatypes like 32-bit floats and 64-bit integers are problematic, interop with JS and DOM APIs is slow. These things can only be improved with browser cooperation, which sort of defeats asm.js's main advantage of working in any browser. Native Rust support would be far better.
    - Touche 12y ago
      All of those things you mentioned are currently being worked on and will be added to JavaScript directly.
      - modeless 12y ago
        What's the solution being worked on for code size?
        azakai 12y ago
        Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip). You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.

345 points by dherman 12y ago

camus2 12y ago

When can I expect Servo to be in Firefox instead of the current engine? 2015/2016? do you have a rough idea?

Narretz 12y ago
As far as I know there are no short- or even mid-term plans to integrate Servo into Firefox. It's still a research project first. Rust for example doesn't even have a stable API yet.
kibwen 12y ago
There are no plans yet to ever integrate Servo directly into Firefox. At the very least Servo will certainly exist as a standalone browser engine (and unlike Gecko, Servo is designed to be embeddable, so it will be an actual alternative to Webkit in that space). The biggest impetus for Servo at the moment is that it's researching the biggest wins to be gained from concurrency and parallelism in browser engines, thereby guiding efforts to tack such things onto Gecko.
- Symmetry 12y ago
  Well, then I'll hope for a Servo equivalent of Luakit before too long.
fournm 12y ago
It may never happen--It's a research engine, not necessarily something that's going to replace Gecko anytime soon.
mcpherrinm 12y ago
Servo aims to be "dogfoodable" by the end of the year. It's still an experiment, really, so you won't be able to get anybody to commit to any plans further than that. The design is significantly different from Gecko that I suspect you'd never be able to wedge it into the existing Firefox, but it wouldn't be entirely implausible if a usable browser called Firefox used Servo within 5 years.
gsnedders 12y ago
As well as the other replies to this, note there's no plan to implement a lot of the non-standard parts of Gecko that Firefox (and most extensions) rely upon, such as XUL and XBL. Servo is concerned with the web (at least for now) — not replicating Gecko's feature set.

talklittle 12y ago

Previous discussion: https://news.ycombinator.com/item?id=7483729 https://news.ycombinator.com/item?id=7483729

kibwen 12y ago
Note that the previous announcement was a bit premature: three weeks ago, on the date of that discussion, Servo was passing Acid2 only on a feature branch. As of two weeks ago the master branch should be passing as well.

acqq 12y ago

Is Servo using GC?

pcwalton 12y ago
For the DOM thread only, yes. All layout data structures are not using the garbage collector.
- steveklabnik 12y ago
  And for those who don't follow Rust closely, it's important that it's "the DOM thread only," as Rust's opt-in GC is on a per-task (thread) basis, so the threads that don't use GC don't even know it's there or running.
  - dbaupp 12y ago
    (Note that Rust doesn't actually have its own GC yet, Servo is just using spidermonkey's JS GC. pcwalton's comment implies it is being used single-threadly though.)
    - metajack 12y ago
      There can be multiple script tasks even within a single page. For example, cross-domain or sandboxed iframes will have each DOM and script in its own task. Also, each of those will have their own layout and rendering tasks.
metajack 12y ago
We use Spidermonkey's GC for DOM objects.

schmrz 12y ago

> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Does anyone care to explain how this would work? If you used OpenSSL from Rust you would still be vulnerable to Heartbleed. Or am I missing something?

jaibot 12y ago
I believe the implication is that if OpenSSL had been written in Rust, Heartbleed would not have been possible.
- joshstrange 12y ago
  Which might be true but seems odd to bring up in the blog post. Also they say: >> Many kinds of browser security bugs, such as the recent Heartbleed vulnerability, are prevented automatically by the Rust compiler. Are they referencing reverse heartbleed here? Browsers themselves were not vulnerable to heartbleed, I don't even this they were vulnerable to reverse heartbleed. There is no way Servo would have prevented the heartbleed bug, no browser could have, I feel like that sentence has no place in this blog post.
  - chimeracoder 12y ago
    > Browsers themselves were not vulnerable to heartbleed, Clients could have been vulnerable to Heartbleed. Feel free to correct me on this, but I believe the only reason they weren't is that Chrome uses OpenSSL compiled without the heartbeat feature, and Firefox uses NSS.
    - azakai 12y ago
      Both Firefox and Chrome uses NSS (although I believe Chrome has a potential plan considering using OpenSSL at some point in the future).
      - gsnedders 12y ago

brson 12y ago

Servo is the kind of project that launches a thousand research papers. Some of the early results are staggering and the project is still just getting going. It is a great example of doing serious research to practical ends. Some examples: - firstly, the entire foundation, Rust, is itself an ambitious research project that solves many long-standing problems in the domain. - Servo has, or has plans for, parallelism (combinations of task-, data-parallelism, SIMD, GPU) at every level of the stack. - The entirety of CSS layout (one of the most difficult and important parts of the stack) is already parallelized, and it's fast. - It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture).

gsnedders 12y ago
> - It puts all DOM objects in the JS heap, eliminating the nightmarish cross-heap reference counting that historically plagues browser architectures (this is part of Blink's "oilpan" architecture). Does Gecko not already do this? Certainly Presto did, and (I believe) Trident does. But to add another bit of research into the mix, and what I think is arguably the most important point: - Builds on all the work around HTML(5) and CSS 2.1, both of which are the best part of a decade of work, both aiming to get browsers actually implementing to specifications, and specifying behaviour in sufficient detail (with minimal undefined behaviour) that a web page cannot easily distinguish two user agents. By actually specifying the web platform as it actually exists, it suddenly makes it far more practical for new browsers to enter the market (compared with the previous hellish situation of the hardest part of developing a browser being reverse-engineering existing browsers with sufficient marketshare that web developers ensure their web pages work in them). If this is shown to be viable, suddenly we have a truly open platform!
- pcwalton 12y ago
  DOM objects are reference counted in Gecko, and there is a cycle collector to collect JS/C++ cycles. They aren't allocated in the JS heap. WebKit is similar, but without the cycle collector.

ChuckMcM 12y ago

This is awesome, I wonder if there is a more constrained web rendering engine somewhere. Something where rather than 'render everything we've ever seen' is 'render the following html 'standards' correctly' (or at least predictably). I was looking for something like this for a modern day sort of serial terminal thing.

metajack 12y ago
We try to support the newer things that are generalizations of the older things. One example of this doing all your list styling with a user agent stylesheet using generated content, instead of hardcoding how list bullets and things work. Also, in some sense, we are doing what you want simply because we don't have a lot of features yet and we prioritize things that are important and things which would have some affect on parallelism or architecture.
wtracy 12y ago
If you're not allergic to Java, there's Flying Saucer: http://code.google.com/p/flying-saucer/ http://code.google.com/p/flying-saucer/ http://en.wikipedia.org/wiki/Flying_Saucer_(library) http://en.wikipedia.org/wiki/Flying_Saucer_(library)
- reitzensteinm 12y ago
  This is one of those only on HN moments. From grandparent's web page: "A long time ago, in a galaxy far far away, I worked for a company called Sun Microsystems. One of the things I did there was to join a renegade band of engineers who were off in Palo Alto working on a technology that nobody within Sun could see any possible use for. That technology was of course Java." http://www.mcmanis.com/chuck/java/ http://www.mcmanis.com/chuck/java/
richdougherty 12y ago
Out of interest, what are the reasons you don't want to be able to 'render everything we've ever seen'?
- 12y ago

sgarlatm 12y ago

I'm curious what Chrome's plans are for the future, in particular related to parallelization. Has anyone seen any articles about that anywhere?

paulirish 12y ago
Eric Seidel talks here about some of the ideas in parallelizing things: https://www.youtube.com/watch?v=4Sm-DbIOqiU#t=818 https://www.youtube.com/watch?v=4Sm-DbIOqiU#t=818 And a 2014 Brainstorm thread with similar ideas: https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5O...

bithush 12y ago

With the bad press Mozilla has had the past few weeks it is easy for people to forget about some of the awesome things Mozilla are working on such as Rust and Servo. I really like the look of Rust and feel it might be the future native language for high performance applications. It is very exciting!

nnethercote 12y ago
Indeed. Brendan's resignation was dismaying and distracting, but we haven't stopped working on stuff. Just after Brendan resigned, I read a comment somewhere to the effect of "I guess that's the end of Firefox OS". Um, no. A major project run by a company of 1,000 employees (and many volunteers) doesn't stop because one person left, even if that person is at the top. Especially when it's progressing well.

macinjosh 12y ago

This is what I see when I run Acid2 in Servo. Perhaps they haven't merged the changes in to the public repo yet. http://cl.ly/image/1b123r220P3u http://cl.ly/image/1b123r220P3u

pcwalton 12y ago
Yes, the fix (a submodule update for rust-layers) is blocked on a Rust upgrade which is currently in progress.

modeless 12y ago

I want Rust scripting support in Servo. <script type="text/x-rust" src="foo.rs"> Since Rust is a safe language this should be possible without compromising security, though I don't think anyone's yet attempted to write a JIT compiler for Rust. Has the Servo team considered this as a possibility?

steveklabnik 12y ago
I'd imagine that a Mozilla project would just focus on compiling to asm.js...
- modeless 12y ago
  There are a lot of problems with asm.js: the heap can't be resized after creation, the code size is really large (esp. with things like C++ templates, which are duplicated for each specialization), threads don't work, datatypes like 32-bit floats and 64-bit integers are problematic, interop with JS and DOM APIs is slow. These things can only be improved with browser cooperation, which sort of defeats asm.js's main advantage of working in any browser. Native Rust support would be far better.
  - Touche 12y ago
    All of those things you mentioned are currently being worked on and will be added to JavaScript directly.
    - modeless 12y ago
      What's the solution being worked on for code size?
      - azakai 12y ago
        Code size currently is avoid equivalent to native builds, if you gzip both of them. The emitted code is basically similar to a native build except it's in text format (so the difference mostly vanishes after gzip). You mentioned things like templates in C++ - those will be an issue in asm.js just as they are in a native build, no more and no less.