Hacker News new | ask | show | jobs
by jruderman 4102 days ago
Servo is already hooked up to a (very old) version of SpiderMonkey, but it's missing enough DOM features that most pages hit errors. This Steam page hits "ele.canPlayType is not a function", "document.write is not a function", and "link.href is undefined".

Last I heard, Servo does not plan to support plugins such as Flash. I'm not sure if the existence of Shumway changes this.

1 comments

Fun times ahead if document.write isn't already supported. When I rewrote Gecko's HTML parsing, accommodating document.write was a (or maybe the) dominant design issue.
I'm quite curious, why document.write is so hard to implement compared to other methods ? Is it not working a bit like innerHTML ?
It's quite different from innerHTML, since document.write inserts source characters to the character stream going into the parser, and there's no guarantee that all elements that get opened get closed. There's even no guarantee that the characters inserted don't constitute a partial tag. So document.write potentially affects the parsing of everything that comes after it.

For this to work, scripts have to appear to block the parser. However, it's desirable to start fetching external resources (images, scripts, etc.) that occur after the script that's blocking the parser. In Firefox, the scripts see the state of the world as if the parser was blocked, but in reality the parser continues in the background and keeps starting fetches for the external resources it finds and keeps building a queue of operations that need to be performed in order to build the DOM according to what was parsed. If the script doesn't call document.write or calls it in a way that closes all the elements that it opens, the operation queue that got built in the background is used. If the document.write is of the bad kind, the work that was done in the background is thrown away and the input stream is rewound. See https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_... for the details.

For added fun, document.write can write a script that calls document.write.

What a mess. To support a stupid HTML feature, the browser's parser has to be set up like a superscalar CPU, retirement unit and all. Hopefully the discard operation doesn't happen very often.

i86 CPUs have to do something like this if you store into code just ahead of execution. That was an optimization technique marginally useful in the 1980s. Today it's a performance hit. The CPU is happily looking ahead and decoding instructions, when one of the superscalar pipelines has a store into the instruction stream. The retirement unit catches the conflict between an instruction fetch on one stream and a store into the same location in another. The CPU stalls as instructions up to the changed instructions are committed. Then the CPU is flushed and cleared as for a page fault or context switch, and starts from the newly stored instruction.

Only x86 machines do this, for backwards compatibility with the DOS era. The same thing seems to have happened in the browser area.

(Prospective fetching should be disabled on devices where you pay for data traffic. Is it?)

document.write is pretty wild, as it can modify the HTML token stream directly, e.g.

  <html>
    <script>
    document.write("<h");
    </script>1>
    This is a h1 title
    <script>
    document.write("<!-");
    </script>-
    This is commented
    -->
  </html>
(From http://www.reddit.com/r/rust/comments/2zir9s/html5ever_proje... )
What?! Why. why. why would anyone ever need this, and why would it ever be made available? I'm just completely dumbfounded by this.
Apparently a lot of the older webpages do stuff like this. You could have a table being outputted by nesting for loops for the `<table>`, `<tr>`, and `<td>` opening/closing tags. It's a small step from here to constructing tags bit by bit.

I don't see people doing it in modern websites (doesn't mean there aren't), but we sort of have to support all of the Internet, so...

We're actively working on document.write and as far as I know have future-proofed the design so that adding it won't involve massive rewrites.