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

LibreOffice running natively in the browser via WebAssembly

lab.allotropia.de

Post reply on HN
Print view View original

91–100 of 216 posts

Re: LibreOffice running natively in the browser via WebAssembly

#91

Post by thorstenb »

squarefoot wrote: post #69

Impressive, although much slower compared to the native one, at least on this (admittedly not stellar) 4300GE machine: the about window takes like 5 seconds to display, and page scrolling is a lot slower. Also caching doesn't seem to work: if I close it and load it again it seems to start the download/compilation process again, which is both a network and resources hog. Didn't wait for it to complete though, so I can…

Caching is a prob, due to the current size - what works here is:

* FF: set browser.cache.disk.capacity to something >300MB, then set browser.cache.disk.max_entry_size to at least 150MB

* Chrom{e|ium}: start browser from cmdline, via `chromium --disk-cache-dir=/var/tmp/foo --disk-cache-size=2147483647`

(I'd not recommend this for production setups, obvsly .. ;))

Re: LibreOffice running natively in the browser via WebAssembly

#93

Post by LeanderK »

mynameismon wrote: post #71
deathanatos wrote: post #41

Earlier quoted context omitted.

300 MiB. & … "a bit" — it takes nearly 20 seconds on "Gigabit" fiber. (312 MiB in 19.22s, or 136 Mbps.) Runs shockingly smoothly once it starts, though.

Funny, it took me approximately triple the time on a 60 Mbps connection. Makes me wonder if its throttled from source due to a network overload.

yeah, 300mb is not nothing but also not that much. Using full speed it shouldn't take that long.

Re: LibreOffice running natively in the browser via WebAssembly

#94

Post by xenonite »

tkgally wrote: post #38

In Safari on iPadOS and MacOS, after a minute or two of downloading, I got the following message: Application exit (TypeError: Cannot convert "undefined" to int) The page did finish loading and compiling in Chrome on my Mac. Menus, text input, etc. seemed to work but were sluggish, just as the standalone LibreOffice was for me on my ten-year-old MacBook Pro. (It works fine on my M1 Mac mini.)

Safari sadly does not support the required WebAssembly module sizes.

Re: LibreOffice running natively in the browser via WebAssembly

#96

Post by thorstenb »

rcarmo wrote: post #84

Interesting, since it makes me wonder if it could actually be usable if you stripped out Qt and flattened things "down" to a simpler widget set and rendering engine, but completely unusable on all my machines.

Longer-term, we need to move to browser-native GUI, yep. The nice bits though - the entire document loading, rendering & editing works in the browser now.

Re: LibreOffice running natively in the browser via WebAssembly

#97

Post by sgjohnson »

deathanatos wrote: post #41
syrusakbary wrote: post #2

Note that it will download around ~300Mb of data directly to your browser, so it might take a bit to load from slow connections. Here's the related video from FOSDEM: https://fosdem.org/2022/schedule/event/lotech_lowa/

300 MiB. & … "a bit" — it takes nearly 20 seconds on "Gigabit" fiber. (312 MiB in 19.22s, or 136 Mbps.) Runs shockingly smoothly once it starts, though.

> Runs shockingly smoothly once it starts, though.

On what hardware? I've got a 2019 MacBook Pro with i9 and 32 GB of RAM, and there's a noticable delay (I'd guess 200~400-ish miliseconds) when clicking any elements with Firefox or Chrome.

Re: LibreOffice running natively in the browser via WebAssembly

#98

Post by thorstenb »

iggldiggl wrote: post #87
mikewarot wrote: post #73

The fact that it runs at all is an amazing achievement. Kudos to the team that managed to shoehorn it in. What is likely to be seen as a bug by others, is actually the thing that gives me hope. There's no way for a WebAssembly program to access the host file system. I hope it stays that way. If the Wasm host can, in a foolproof and easy to verify way, offer the user dialog boxes to read/write single files... we'd hav…

> Preventing a process from deciding itself which files to access disables so many attack vectors. It also disables a lot of existing use cases and file types (basically any multi-file file format): Multi-part archives, multi-part video files, playlists, videos with separate subtitle files, HTML documents containing links to other local HTML documents or referencing various sub-resources (images/videos/audio/style sh…

With LibreOffice, the nice thing is you can chose. if you want all of the above - install the native version.

Re: LibreOffice running natively in the browser via WebAssembly

#99

Post by thorstenb »

syrusakbary wrote: post #22
noduerme wrote: post #20

Going to "Open..." a file seems to show a whole Android filesystem. Is this actually running some minimal version of Android in WASM?

I believe it's been compiled with Emscripten under the hood. So it's using the Virtual FS provided there.

Yep

Re: LibreOffice running natively in the browser via WebAssembly

#100

Post by tokai »

KronisLV wrote: post #89
unixhero wrote: post #58

Earlier quoted context omitted.

Why in the world don't you switch to Libre Office?

> Why in the world don't you switch to Libre Office? As someone who uses LibreOffice to the point that it has displaced MS Office (which is no longer installed on any of my private devices, only work ones), i have to agree that it's the better option of the two. However, one could make the argument for OpenOffice that it's pretty much stable/finished/dead at this point which also means that it's unlikely to have unex…

But its not stable/finished - only dead. The devs just left the project. OO has only been getting sparse bug and security fixes for half a decade now. Security issues stay open for years.
Post reply on HN