Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Week in Servo 43 (submitted via Servo itself)

blog.servo.org

Post reply on HN
Print view View original

21–25 of 25 posts

Re: This Week in Servo 43 (submitted via Servo itself)

#21

Post by Manishearth »

oneeyedpigeon wrote: post #17
perlgeek wrote: post #13

Earlier quoted context omitted.

This bug (input field doesn't scroll automatically, but spills its text into the surrounding elements) is a good demonstration of just how many, many small details you have take care of when implementing a browser engine. A really monumental task. The servo devs have my respect!

Maybe I'm missing something hugely obvious, but shouldn't the input field be rendered using a native control which would preemptively eliminate that bug and reduce the need for rewriting code that's been written countless times before?

dumbmatter is correct, we can't arbitrarily style things via CSS with native controls.

Eventually we do want them to look more like the controls on the platform they're running on, though.

Re: This Week in Servo 43 (submitted via Servo itself)

#22

Post by pcwalton »

oneeyedpigeon wrote: post #17
perlgeek wrote: post #13

Earlier quoted context omitted.

This bug (input field doesn't scroll automatically, but spills its text into the surrounding elements) is a good demonstration of just how many, many small details you have take care of when implementing a browser engine. A really monumental task. The servo devs have my respect!

Maybe I'm missing something hugely obvious, but shouldn't the input field be rendered using a native control which would preemptively eliminate that bug and reduce the need for rewriting code that's been written countless times before?

> shouldn't the input field be rendered using a native control which would preemptively eliminate that bug and reduce the need for rewriting code that's been written countless times before?

Broadly speaking, native controls don't like being composited into OpenGL scenes (which are necessary for things like 3D transforms).

Re: This Week in Servo 43 (submitted via Servo itself)

#23

Post by Rexxar »

enimodas wrote: post #16
Rexxar wrote: post #9

Earlier quoted context omitted.

Wonderful, you just make aware of the software that do exactly what I need today :-)

There's also https://github.com/thetarkus/WebMCam which records in a more modern format than gif.

Looks potentially better but I experience lots of crash/freeze

Re: This Week in Servo 43 (submitted via Servo itself)

#24

Post by pcwalton »

(Copying my comment here from Reddit /r/rust:)

Just to repeat, because this was somewhat buried in the article: Servo is now a multiprocess browser, using the gaol crate for sandboxing. This adds (a) an extra layer of defense against remote code execution vulnerabilities beyond that which the Rust safety features provide; (b) a safety net in case Servo code is tricked into performing insecure actions.

There are still plenty of bugs to shake out, but this is a major milestone in the project.

Re: This Week in Servo 43 (submitted via Servo itself)

#25

Post by nickysielicki »

FreeFull wrote: post #15
nickysielicki wrote: post #8

Earlier quoted context omitted.

For anyone wondering how to do this on linux, I use recordmydesktop and ffmpeg to make small webms (~2mb). Highly recommend it. `recordmydesktop --windowid $(xwininfo)` and click the window you want to record. `ffmpeg -i out.ogv -o final.webm` and you're done! recordmydesktop is available in most distros afaik.

How come passing $(xwininfo) works? xwininfo outputs a lot more than just the window ID

I don't know why I said that it would. It doesn't.

This works, though:

    recordmydesktop --windowid $(xwininfo | grep 'Window id' | cut -d' ' -f4)
though its worth noting that it theoretically could detect that its being redirected and only output the window id
Post reply on HN