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

Early stages of Google Docs support in the Ladybird browser

twitter.com

Post reply on HN
Print view View original

71–80 of 89 posts

Re: Early stages of Google Docs support in the Ladybird browser

#71

Post by tomcam »

olliej wrote: post #66
xnx wrote: post #49

Is this using Google Docs new(ish) canvas-based rendering? https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... Honestly not sure if it's harder to support canvas or DOM based rendering.

What do you mean by harder to support? Supporting - in the sense that it works - canvas rendering is much simpler than even minor amounts of the DOM. The problem of course is that you're replacing compiled C++ that is doing the normal DOM/CSS layout and rendering with someone implementing the layout and rendering in JS (sans actual bitblitting, etc).

> canvas rendering is much simpler than even minor amounts of the DOM

How is the accessibility picture?

Re: Early stages of Google Docs support in the Ladybird browser

#72

Post by mdaniel »

mhh__ wrote: post #67
senkora wrote: post #56

Earlier quoted context omitted.

I think a significant factor in this is that C++ simply has better abstractions for building large codebases than C does. Any big enough C project is gonna turn out a bit funky.

For quite a long time now I have said that the future for the Linux kernel could easily be C++ rather than rust. Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.

> C++ would prevent so many bugs

https://chromereleases.googleblog.com/search/label/Stable%20... and control-f for "High CVE"

This from the company with arguably the best security researchers on Earth, and probably unholy amounts of internal fuzzing and static analysis tooling

Re: Early stages of Google Docs support in the Ladybird browser

#73

Post by rvz »

marginalia_nu wrote: post #68
als0 wrote: post #60

Earlier quoted context omitted.

> And Google's Chromium is simply a convoluted mess, chockful with vulnerabilities and memory corruption errors. I'm sorry, but Ladybird is written in C++. Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors.

> Therefore, it's inevitable that it will have vulnerabilities and memory corruption errors. Is it though?

Yes it is inevitable, as long as it is using C++ then you will still get memory corruption vulnerabilities.

If it was written in Rust on the other hand, it eliminates those specific class of vulnerabilities.

Re: Early stages of Google Docs support in the Ladybird browser

#74

Post by mhh__ »

mdaniel wrote: post #72
mhh__ wrote: post #67

Earlier quoted context omitted.

For quite a long time now I have said that the future for the Linux kernel could easily be C++ rather than rust. Rust is very cool and have no issue with it in the kernel tree but C++ would prevent so many bugs and eliminate so many lines of code. It's just ego.

> C++ would prevent so many bugs https://chromereleases.googleblog.com/search/label/Stable%20... and control-f for "High CVE" This from the company with arguably the best security researchers on Earth, and probably unholy amounts of internal fuzzing and static analysis tooling

Note that the baseline is C not C++ used badly.

Re: Early stages of Google Docs support in the Ladybird browser

#75

Post by olliej »

tomcam wrote: post #71
olliej wrote: post #66

Earlier quoted context omitted.

What do you mean by harder to support? Supporting - in the sense that it works - canvas rendering is much simpler than even minor amounts of the DOM. The problem of course is that you're replacing compiled C++ that is doing the normal DOM/CSS layout and rendering with someone implementing the layout and rendering in JS (sans actual bitblitting, etc).

> canvas rendering is much simpler than even minor amounts of the DOM How is the accessibility picture?

If you’re making a site using canvas to render UI elements you are taking it upon yourself to implement a lot of standard functionality yourself, similarly even basic text entry, let alone editing, is much more complex than people seem willing to accept.

At google’s size/cash implementing these things might be achievable, but I recall many people/projects over the years that decided to do in canvas rather than using the available engine (often times a belief that their desire for pixel perfect positions was reasonable, and more than made up for needing to draw everything and manage text entry themselves) always looks easy at first glance, typically because the authors don’t use accessibility tools and most who I interacted with were English-first devs who believe one keypress event == one letter. So you end up with yet another English-only (and I really do mean English specifically here, not Western European) and inaccessible rendering engine for a web page, that typically could have achieved 95-100% of what they wanted, with a bunch of the remainder being stuff that doesn’t work for people with accessibility issues.

Re: Early stages of Google Docs support in the Ladybird browser

#76

Post by zinekeller »

jrochkind1 wrote: post #64
pavon wrote: post #20

Earlier quoted context omitted.

To second this, many of the nitter instances and other twitter flattening sites are blocked by corporate security scanning proxies. For those in that situation, note that you can replace the domain name with twitter.com to get the original URL.

Side issue, but why do corporate security scanning proxies block nitter?

I'm not personally aware of filters targeting Nitter instances significantly, but I'm aware of whitelisting only the top 10 million sites (blocking "undesired" things of course) and manually asking IT if you are visiting a low-traffic site. This stops a lot of phishing attacks but at the same time only allowing ~9.5 million sites is still too small.

Re: Early stages of Google Docs support in the Ladybird browser

#77

Post by nilsb »

svnpenn wrote: post #55

note, native Windows support is not planned: https://github.com/SerenityOS/ladybird/issues/113

While technically true it would be more accurate to say that no features are _planned_ in advance and it’s entirely up to individual contributors to decide what they work on.

Re: Early stages of Google Docs support in the Ladybird browser

#78

Post by stephen_g »

lzazz wrote: post #57
hbn wrote: post #25

Earlier quoted context omitted.

From the FAQ [1] > Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff. > Sure you can. Don’t listen to armchair defeatists who never worked on a browser. [1] https://awesomekling.github.io/Ladybird-a-new-cross-platform...

Sure you can start a new browser engine, but this one is nowhere near usable, and it will probably never be.

Well I'm glad they're trying and not listening to the defeatists!

Re: Early stages of Google Docs support in the Ladybird browser

#79

Post by stephen_g »

Shared404 wrote: post #8
nonethewiser wrote: post #6

Clearly I have no idea what Ladybird browser is. Why should I be impressed? I would expect every browser to be capable of this. EDIT: Lots of great answers. Thanks everyone. Glad this inspired such lively discussion.

Ladybird is a from-scratch browser on a from-scratch OS.

Well it is now, but is also more. Originally Ladybird was the cross platform port of the from-scratch browser on a from-scratch OS. If I recall correctly, the browser on Serenity was just called 'Browser', and then Ladybird was created to wrap the LibWeb / LibJS engine from that in a Qt interface that could run on Linux and Mac, and then the Browser program in Serenity was also renamed to Ladybird.
Post reply on HN