
Webkit.js - ndesaulniers
http://trevorlinton.github.io/
======
Yoric
Nice one. Next step is porting $YourFavoriteWebkitBrowser to Firefox OS :)

------
wildpeaks
That reminds me of the hilarious talk _" The Birth & Death of Javascript"_
where everything get converted to _asm.js_ , even operating systems.

[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

~~~
shayief
Check out this kernel built on V8 engine, designed to run JavaScript code
[https://github.com/runtimejs/runtime](https://github.com/runtimejs/runtime)

------
Rinum
Very nice and with JS support it would be perfect! I wonder if this is a
solution to potential XSS attacks with embeded iframes or embeded user-
generated html+css+js.

~~~
m1sta_
I'm quite interested in seeing this evolve, but for your purposes will
postMessage not do?

------
i_am_ralpht
In Chrome (for me, on 64bit Linux) it consumes 176MB of RAM -- for all of
WebKit + Cairo + FreeType/HarfBuzz/etc -- it's most of an OS right there.

GMail, a webapp email reader, is currently taking 368MB of RAM. Insane!

~~~
reubenmorais
"Web browsers have never been more memory efficient, and web pages have never
had more memory bloat." \- someone on Twitter a couple days ago

------
mantraxC
I remember when for some reason people started writing SVG and HTML engines
for Flash. Because, I don't know. They wanted to put a browser in your
browser, so you can browse while you browse.

The engines worked, but where are they now? Nowhere. Just like Flash.

No matter how much effort you put into something, no matter how functional it
is, now matter how much geek cred you'll get for it, if it doesn't have some
sensible use, at least superficially, it'll linger and die. Wasted effort.

Just because you can do something...

------
heydenberk
It's a little contrived, but a "practical" use of this might be for an online
HTML editor to embed the document (or display a preview) without any
interference from the parent document.

~~~
schrodinger
You can do that via iframe as well

~~~
leorocky
If you allow custom HTML via an iframe and make it shareable you have to host
the iframe from a different domain, otherwise it's XSS vulnerability heaven.
The trick will be authentication because separate domains don't share sessions
(and you wouldn't want a secured domain access to your session anyway) but you
can do communication via postMessage.

------
elwell
Can't wait for JS support so I can:

    
    
      <html>
        <body>
          <iframe src="http://trevorlinton.github.io/"></iframe>
        </body>
      </html>

~~~
bjeanes
[https://help.github.com/articles/setting-up-a-custom-
domain-...](https://help.github.com/articles/setting-up-a-custom-domain-with-
github-pages)

~~~
ricket
Erm, look at the URL of the original page...

------
LukeB_UK
Getting errors on chrome 35.0.1916.153 on Linux Mint.

56 on line 34 in webkit.api.js

Uncaught #<error> on line 15633 in webkit.bin.js

~~~
tlinton
If you put in any HTML that requires webkit to go out to hte network it
crashes since network requests are disabled in the demo.

~~~
LukeB_UK
This was using the demo code that was already on the page.

------
copremesis
straight up broken

------
PLenz
Anyway to get this to run in node with the output going to say Cairo? It'd be
a fun little project to see if you could build a simple but working browser in
nothing but JS.

~~~
msvan
And then, getting the browser running itself in the in-browser browser.

~~~
nnnnni
Now THAT would be a sandboxed browser.

Also, even though people tend to not like this kind of thing here, it has to
be said: Yo dawg...

------
dingdingdang
Why? Not being dry/evil, simply just interesting in whether this project has
practical offshoot or is pure fun (..)?

~~~
gol706
Doing this in the browser might be a little silly, or at least I can't
immediately think of a good use, but I think using this in a node.js program
as an easy way to template something out and render an image/pdf locally could
be useful.

~~~
dingdingdang
Of course, that's cool point!

------
grimtrigger
Pretty cool. There's been a push to make HTML run everywhere, but this proves
you can make X run on HTML.

Maybe someday we'll code apps in Objective-C/Java that run in the browser, all
inside a canvas.

~~~
emilsedgh
That would be a sad day. Layers upon layers of complexity, abstraction,
technologies, etc.

Please make it easier. More simple.

~~~
Everlag
I'd like you to consider the fact that your operating system is already a
significant abstraction and that a browser is essentially a virtual machine
that allows to download and run programs from any source safely.

You know all those malware issues regarding unsigned or compromised
executables? Not a problem in the wonderful world where programs are incapable
of acting overly malicious. There're specs like webgl and webcl that lets you
take the scary topic of graphics programming, which is communication to an
external piece of hardware, and make that as safe as loading some javascript
to sort a table by dollar value.

</rant>

------
notastartup
this is pretty cool but network requests and javascript support would make it
even more crazier.

I viewed the html source for this page and pasted it. I was quite impressed.
It looks like this is supposed to be a browser engine written in Javascript?

So essentially we would have a sandbox browser within a browser? That would be
awesome.

~~~
ndesaulniers
> javascript support would make it even more crazier

There's interesting research being done in the area of meta-circular
interpreters. There's techniques for speeding them up; they're not as slow as
I'd expect. For example, one interpreter can do type analysis and rewrite
chunks of code.

~~~
notastartup
another interesting question would be will webkit.js support single origin
policy? basically, what if you could use webkit.js like an iframe but with the
ability to execute javascript and manipulate that window.

------
atomical
I've been watching this project hoping that eventually PDFs could be rendered
on the client.

~~~
qhoc
You can do that today already using toDataURL()
[https://developer.mozilla.org/en-
US/docs/Web/API/HTMLCanvasE...](https://developer.mozilla.org/en-
US/docs/Web/API/HTMLCanvasElement) to convert canvas to image and then use
jsPdf [http://parall.ax/products/jspdf](http://parall.ax/products/jspdf) to
convert that image to pdf

------
dag11
I thought it was a static rendering, but then I put in a marquee tag and it
moved flawlessly across the screen.

Impressive. I can't say I see the practical implementations of this, but I'm
sure there's some. But it's impressive nonetheless.

~~~
pfraze
Rendering HTML to WebGL textures would be big, which I think this could do -
though probably not as performantly as the browser could. It's currently not
possible, partially due to security concerns if I remember right.

~~~
ndesaulniers
Awesome idea! I've seen tricks where CSS 3D transforms were used to position
the entire DOM within a scene rendered in Canvas, but that approach is
extremely limited. [0]

Theoretically, now you could render the DOM to a texture instead of to the
screen and do some sweet deferred rending.

== Edit ==

Looks like one of Mozilla's Distinguished Engineers blogged about the
technique. [1] [2] The creator of emscripten used this technique to render
tweets as a texture in the bannabread demo. [3]

[0] [https://medium.com/@deathcap1/six-months-of-voxel-
js-494be64...](https://medium.com/@deathcap1/six-months-of-voxel-
js-494be64dd1cc)

[1] [http://robert.ocallahan.org/2011/11/drawing-dom-content-
to-c...](http://robert.ocallahan.org/2011/11/drawing-dom-content-to-
canvas.html)

[2] [https://developer.mozilla.org/en-
US/docs/Web/HTML/Canvas/Dra...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Canvas/Drawing_DOM_objects_into_a_canvas)

[3]
[http://kripken.github.io/boon/screens/game.html?low,low](http://kripken.github.io/boon/screens/game.html?low,low)

~~~
rl3
One of the drawbacks with rendering DOM content to a Canvas/WebGL texture is
that interactivity is lost in the process. At the very least an intermediate
layer would have to be created that pipes scene input into DOM input.

The nice part about CSS 3D transforms is that interactivity is maintained, and
it's still hardware-accelerated. A fantastic example of this was made by the
creator of Three.js over a year ago:

[http://mrdoob.com/lab/javascript/threejs/css3d/](http://mrdoob.com/lab/javascript/threejs/css3d/)

As you said above, there are severe drawbacks with that approach. It is very
limited in terms of what's possible compared to a traditional 3D scene.
Moreover, since CSS 3D transforms are essentially DOM content rendered to a
texture, rasterization occurs, and as such there isn't clean scaling, even
with SVG content.

~~~
benjaminjackman
Here is another really good one:
[http://mrdoob.github.io/three.js/examples/css3d_periodictabl...](http://mrdoob.github.io/three.js/examples/css3d_periodictable.html)

------
jstsch
Neat. Getting some good use out of HTML2Canvas as well. But always wondering
why there is no way to get a bitmap from screen... something like
window.getPixels(x, y, width, height).

~~~
jevinskie
There are privacy and security concerns to address. Similar to this situation:
[https://hacks.mozilla.org/2010/03/privacy-related-changes-
co...](https://hacks.mozilla.org/2010/03/privacy-related-changes-coming-to-
css-vistited/)

~~~
nawitus
One solution is for the browser to provide a "anonymized" bitmap picture, e.g.
setting the links to default colors. I don't know how feasible that is. It
would require a new rendering of the page, at least.

~~~
euank
That's not a solution for the general problem of getPixel + iframes though.

Here, I'll give a simple example. Let's say there's a site that uses cookies
to track logins. For example, hacker news. Now, hacker news does have the
X-Frame-Option Deny, but let's assume it doesn't.

So to figure out my hacker news username, all you have to do now is create an
iframe with hacker news, and then getPixel on the area of the frame that
contains usernames, run some trivial OCR, and done.

Now, this issue is even more serious in other instances. For example, google
talk widgets are embedded by iframes I believe.

In both these cases, a fresh rendering would still have the inappropriate
material due to cookies. If cookies aren't sent, e.g. you do a fresh render in
a private tab, it would still have security concerns for anything that
displays different, sometimes private, content based on ip address.

For an example of that, you could render "private.internal.company.localsite"
in an iframe and if a visitor from that company visited, even a cookie-less
load would probably show private data due to the internal site relying on
ip/nat controls.

~~~
tlrobinson
There's no reason you couldn't apply the exact same "same origin policy" to
elements (iframes, images, etc) when rendering into a bitmap.

~~~
euank
You could, but it would change scope a little. Right now, it's reasonable to
expect that information will not be leaked to external servers, but user
interactions can be faked.

On an information only webpage (no user interactions) there's no need to have
the X-Frame-Options to remain secure. If there's a way to access the data in
that frame suddenly, that changes the necessity of that header.

~~~
tlrobinson
I'm not sure what X-Frame-Options has to do with it. I'm suggesting either not
allowing rendering of bitmaps containing different origin iframes/images, or
blanking out those elements in the rendering. Canvas does exactly that by not
allowing different origin images to be drawn into a canvas element.

------
ozten
FirefoxOS will host Safari / Chrome apps, before iOS will allow a Firefox.

Open FTW.

~~~
atonse
What exactly are iOS users missing in Safari, in your opinion, that they would
get from Firefox? I can see that Chrome has some cool sync features if you're
into that sort of thing. But it still uses WebKit. And from what I've
observed, people seem happy with the "Chrome" app in the app store, even
though it uses a handicapped renderer. (Although in iOS 8, it won't be
handicapped anymore, and will be as powerful as native Safari)

(Also WebGL support is new in iOS). Are people really clamoring for the
Firefox engine to be supported in iOS?

~~~
nnnnni
The funny thing is that the "RAWR NO SAFARI, ONLY CHROME!" people don't seem
to realize that both are WebKit at the core. Sure, some features are in Chrome
first, but that's only because Apple is very cautious when releasing the new
features to the general public.

~~~
agildehaus
Chrome forked Webkit over a year ago, creating Blink. They're two independent
layout engines now.

~~~
thefreeman
I believe he is referring to the fact that iOS Chrome is the only version
still using WebKit

~~~
nnnnni
Yes, that's exactly what I meant. I think that a few people may have missed
that due to the fact that my comment is currently at -2.

~~~
cwyers
That's because Apple's TOS only allows their system build of WebKit in
approved apps, so Google can either use approved WebKit or they can go sit on
their thumbs and spin. It's not a voluntary act on Google's part; they would
use Blink if Apple allowed it.

