How can Firefox create the best support for web apps on the desktop? | Hacker News Reader

How can Firefox create the best support for web apps on the desktop?

connect.mozilla.org

80 pointsReadCarlBarks65 comments

I would like browsers to offer a true "local app mode": Locally installed code (HTML/JS) that would be run using the browser runtime, but with enhanced privileges behind a permission model (e.g. the possibility to grant filesystem access etc.).

Currently, developers that need a single thing they can't get from within a browser are generally forced to create an Electron app, which means they essentially bundle an outdated (and often never updated) version of a browser with their app. It would be much better if you could just use the already installed, always updated browser as the runtime for your "local" app.

That would also create an incentive to develop in the browser ecosystem, and possibly move to a PWA - or at least it would show why devs prefer "real" applications to PWAs.

Genuine question: is this not exactly what the Tauri project aims to do?

And primatejs just released desktop support

Looks like it's very close to what I meant!

I was thinking of something like `/usr/bin/firefox --webapp-mode /var/opt/path/to/approot/` (in my model, the browser would contain code to load some standard webapp format, while with Tauri it looks like the app bundles a small piece of code that loads local webkit) but that's just a detail.

The downside of Tauri is that you likely run the built-in runtime with regular (full) access, while with a browser-controlled flow, the browser could enforce a permission system.

FWIW Tauri has a comprehensive permission system

I think the concern is not XSS but rather trusting the first party developer of the binary that hosts the webview.

how is that different than apps off an app store?

On platforms that have app stores (including desktop operating systems like Windows, some distributions of Linux, and especially macOS), the apps you download from the store are sandboxed (UWP; Flatpak/AppImage; Apple) far more than raw binaries. Tauri apps are raw binaries; Electron apps are too; those are both different from visiting a webpage in a browser, regardless of whether such navigation happened manually or automatically (as in from a PWA shortcut).

It's what Microsoft did with "HTA" back in the mid-1990s; this is nothing new.

...and we'll see a repeat of the problems it caused Microsoft back then trying to improve Windows and Internet Explorer over time while still maintaining backwards-compatibility with a surprisingly large number of already-distributed HTAs (HTAs were popular for things like magazine CD demo-disk catalogs, computer hardware driver splash-screen GUIs, kiosk apps, that kind of thing - by 1998 if you didn't care about Netscape support you could take full-advantage of Trident (MSHTML)'s hacked-on support for parts of DirectX graphics (gradients, alpha-transparency, smooth animations) - the only alternative was VB5/VB6 and I think/hope it was obvious to everyone at the time that VB's days were numbered; and don't forget that Macromedia put decent effort into making Flash work well for standalone "Flash Projectors" - and you could embed SWFs in your HTA too; so this incredibly capatable HTML+CSS or HTML+Flash-based "interactive experiences" were expected to quickly become the standard for desktop multimedia.

...well, they didn't: instead .NET's WinForms (a marginal improvement over VB6) is still dominant for Windows fixed-size-window RAD GUIs, while HTAs started to suffer decline when XP shipped in 2001 because of the breaking-changes between IE4, IE5, and IE6 (hence even more hacks like Conditional Comments) - and security-folk sensibly reminded us that it was not a good idea for magazines/trade-shows/etc to distribute CD-ROM discs with autorun HTAs containing embedded ActiveX controls running under full-trust on every Windows machine from 95 to XP.

Mozilla of 2024 needs to avoid repeating Microsoft's self-inflicted issues.

-----

As for me? For now, I'd really rather just have a fork of the Blink layout engine that can run off XML and CSS and would be driven by something like a COM interface to the DOM - which means Blink doesn't need to bring its own JavaScript engine, which makes the system more secure - and means they'll finally be able to have a Blink-based page render that doesn't require 4 separate isolated processes consuming gigabytes of RAM (looking at you, GitKraken).

Yep, Internet Explorer had this 'security zone' feature which privileged localhost/file urls, except it was too easy to confuse it about what 'zone' it was running in, leading to endless security bugs. Probably the worst feature of the browser.

See Chrome’s Isolated Web Apps spec that they’re starting to launch: https://chromestatus.com/feature/5146307550248960

Well, I'd like that but not from Google.

Oh wow, they're finally doing it! I've been waiting for this[1] since Web Bundles became a thing, but after 6+ years I was starting to get the impression it wasn't going to happen. I guess I haven't been following it super closely.

[1]: https://news.ycombinator.com/item?id=17778489

This is still so many steps to recreate what Flatpak / mobile app models / etc are already close to, but with less freedom for developers by still being restricted to the web stack.

The big difference is that these apps would be cross-platform, where all of your listed solutions only run on one platform.

But it would have the advantage of working in a proven model, whereas flatpaks are notorious for causing breakage for so much that uses it.

I am OK with flatpaks in theory, but there are years-old bugs with flatpak permissions that simply aren't getting resolved. Something is off with the feedback loop.

There is many? :-)

Basically Active Desktop applications from Windows 98, Symbian Web Runtime, or WinJS apps on Windows 8, no thanks.

I used to like them as much as I like Electron apps.

How is that not just PWAs?

> grant filesystem access

That actually already exists nowadays

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

> It would be much better if you could just use the already installed, always updated browser as the runtime for your "local" app.

So that an update, automatic if at all possible, can break all the apps at the same time.

Many people already said this, but isolation is core. From the moment I press "install pwa": separate desktop icon, separate storage. I should be able to choose for which profile the app is installed (to support multiple profiles) and the window should be managed separately.

Since I use kwin, possibly a separate window class too, so I can easily make rules specifically for the installed app. file system access would be great, with long term storage, so i can stay authenticated for long time.

I should be able to tell file extensions to be opened by the pwa on my desktop. Notifications should be available too. A permission management window for installed pwa would be great.

Something that would be cool is some sort of storage within Firefox sync, so that installing the pwa somewhere else restores my status and settings

I sort of achieved this by 1) creating a separate profile for a web app, 2) create a Desktop File which points to that profile, with a `--class` option set to the app's name. It seems that the logins are staying for as long as the website allows.

The caveat is that the `--class` option doesn't seem to always be reliable; sometimes the window still gets grouped with the normal firefox instances in the task bar. I haven't got around to find out whether it's the fault of firefox or kwin.

I would be happy to just get the old PWA mode back. Turn a webapp into a window.

Exactly this. I have to use Chrome (or one of its non-Google flavors) to easily create dedicated Desktop apps for websites. I would prefer to use Firefox but they killed this feature long ago.

Glad Firefox is revisiting PWA/WebApps

Anyone know why Firefox killed PWA support?

I think it's addressed in the article:

> As you may know, we built a prototype for desktop PWAs a few years ago, and unfortunately user testing on our solution showed confusion and lack of perceived value. We didn’t release it because we didn’t have an approach that could meet the needs of power users without causing confusion among the broader user base.

it was live for awhile...don't know why they removed it for that reason. seems like your average user wouldn't know to use a PWA but the power users got screwed.

I think one big problem with web apps is that browser storage is generally seen as ephemeral, causing data that the user would want to keep to be deleted together with relatively meaningless, truly ephemeral data.

For example, I have my browser set to delete cookies on exit. Others use "delete recent history". I don't know if these things also wipe PWA data, but if they do, that can be a nasty surprise.

In Firefox, cookies and "site data" have separately delete settings but definitely can be done. My browser is configured to delete everything (cookies, data, history) when I close it.

as a pwa developer, that's a continuous concern, lately I was thinking of notifying the users after certain actions to go and save locally the data that's withing the web app(it's all JSON btw) and restore it later when in need, but that's too cumbersome as a solution for many... ¯ \ _ ( ツ ) _ / ¯

The data should pass through to the OS environment app data folder the way you store data in any other app.

The thing I want most is the thing specifically ruled out .. > "it’s not a goal to make it feel like you’re not in Firefox."

I'm perfectly happy to have my app in a pinned tab or bookmark. Do we really need a third kind of bookmark. Why do we need yet another method for installing apps on our desktop.

On a phone I can understand the convenience of saving a bookmark on your home screen, and removing the space consuming address bar, but desktops don't have the same constraints.

I wish they would just make an Electron alternative, but try and do it better. Make it easy to carve out features you don't need to make the process smaller and lighter. Don't need WebGL or Canvas? Don't need audio or video? How small can you make a browser by cutting features?

How cool would it be to visit a website with a bunch of check boxes that allow you to select the features you want for your app runtime, then it compiles an executable for you on demand.

Per app/site theming - Built in 'Dark Reader' for PWA/web pages Make development/programming apps intuitive/fun to tinker with things for new people coming in to development. (For local development)

Make memory management more controllable for firefox, multiple tabs with bloated JS pages using 7GB of 8GB total system RAM gets.. fun (manjaro+xfce, does it on different installs, has for years)

A service level worker for push notifications with the ability to run a local push server easily for testing webapp creation. (Won't work if firefox isn't running, but not that big of a deal, but is, if firefox is using all the RAM.)

Per tab/app containers with bandwidth/resource limitations. Ability to save window sizes, volumes, etc. 'Save States'

By default, nothing outside of the browser address bar hitting 10.* 192.* 0.0.0.0 127.0.* addresses in scripts/apps without user permission/knowing.

Apps accessible only through DoH/DoT only.

Bookmarks manager shouldn't close/minimize when you click a bookmarks link.

Incentive to create FREE web applications and keep them free without micro transactions/some other hidden/rabbit hole fees.

> Recently, other browsers have implemented or enhanced their approach to PWAs, for example by making it easy to install any website as a web app (even if no PWA manifest is provided)

Chrome has had this for at least 5 years, probably longer.

Firefox has had "Site Specific Browser" functionality a long, long time ago.

> Firefox has had "Site Specific Browser" functionality a long, long time ago.

I was using Mozilla Prism but they went and killed it.

https://en.wikipedia.org/wiki/Mozilla_Prism

Never could see the difference between a so called web app and a shortcut to the site in question on the desktop. It is not a standalone application when it depends on the browser runtime. Much rather prefer Mozilla's sadly vanished application platform, where you could create powerful standalone cross platform desktop applications with knowledge of just XML(XUL being a subset) and Javascript. Firefox and Thunderbird themselves were great examples of such apps and it would have been any day a better alternative to Electron, these applications actually respected the look and feel conventions of each OS they ran on.

Mozilla had a separate XULRunner runtime to bundle with your app for it to be fully standalone, or you could invoke it with the locally installed Firefox instance. There were several, like Songbird (media player), FireFTP/FireSSH (originally began as extensions and now available as standalone software)

Easy privacy/identity management per app.

Easy payment processing builtin to browser.

Easy social that spans apps that we fully control. I should be able to see who my hackernews friends are and if we have both chosen what other apps we have in common.

I still can't believe we have to sign up for every single app. Enter all kinds of different payment methods across a variety of payment processors. And are trapped using big tech platforms.

The browser is the killer app but none of these browser makers take it to the next level. Its still same as it was since mid 2000's.

> I still can't believe we have to sign up for every single app.

> Enter all kinds of different payment methods across a variety of payment processors

apple pay is super convenient - merchant gets my payment and my address, but there's also PayPal and Amazon pay and Shopify pay and stripe link. there's a complaint to be had about the nunnery of choices there are, but that's different from the automation not working.

> And are trapped using big tech platforms.

can't do anything about that unless you wanna work with crypto, but then you're using crypto.

we're not still stuck in the year 2000 unless you choose to be.

> sign in with apple/Google/Facebook/whatever has reduced the number of signups for me.

That's an awfully high-risk solution to having to maintain multiple identities.

The last thing I want is to be cut off from my (business) calendar because of something I said in a forum somewhere.

Remember back when having your identity tracked across multiple websites was malicious and websites would do their best to perform the tracking surreptitiously.

Now it's all different - websites having users lining up to dox themselves.

I'm afraid if someone wants to dox many of the online pseudo-anonymous personas I use, they going to have to do all the work to dox me; I'm not lifting a finger to help them, much less actually do it for them.

https://www.youtube.com/watch?v=Nnugnf_2CYM

I agree with most of this.

> Easy privacy/identity management per app.

Now that Passkeys are a thing, browsers could theoretically create an anonymous, ephemeral account for you automatically on any site that requests that. Or alternately/additionally, maybe a "synced localstorage" feature could reduce or eliminate the need to have accounts for many cases.

> Easy payment processing builtin to browser.

This already exists on mobile and works quite well, though desktop support is a bit lacking. https://developer.mozilla.org/en-US/docs/Web/API/Payment_Req...

> Easy social that spans apps that we fully control

User-friendly decentralized social media is an unsolved problem. Maybe if Mastodon or Nostr or Matrix ever overcomes those challenges and starts to take off browsers can start integrating support.

Lack of PWA support is the only reason why I keep other browsers handy, so I'm glad to see some movement on this long-outstanding issue. But I do have some concerns with the tone of this post and I hope they don't try too hard to re-imagine what "web apps" should be and end up with either a half-baked solution or a proprietary one.

I want it to be easier to develop local-only offline apps and I want to verify that they are offline by being able to see if they are sending network traffic in the same way I can currently use browser tools to see what data is coming from this web page. Dealing with service workers for local apps feels like a hack at best.

Every day we stray further from using the web to deliver documents.

It's pretty clear at this point that the web also being a universal zero-installation-required sandboxed application runtime is a much more exciting vision than if it was restricted to only documents.

Why, because you can charge for cramming 50 MB of tracking JavaScript down the pipe to people paying $10 a month for the privilege?

Only if you suck at making web apps.

(Admittedly a lot of people suck at making web apps.)

I used to feel a lot more excitement in 2000 than i feel now.

In year 2000, we were around 24 years younger and the web was still an undeveloped plot of land for kids to play.

Now, it’s mostly a corporate canvas for economic transactions, like the rest of the human experience in the west

The dot-com bubble would like to have a word with you.

That honestly sounds like a you issue, not a browser issue.

I would have killed for the capabilities web browsers have now back in 2000. I was forced to build Java applets to get anything close, and the user experience sucked.

But the user experience sucks far more today. People are opting out. That’s how bad it is.

Websites today offer little over the ones from 15-20 years ago functionality-wise. In fact they have less features in the name of 'simplicity' that results in their being bloated memory hogs with javascript.

It’s maybe an exciting vision, but the existing web tech stack is woefully mismatched for that.

> is a much more exciting vision

"Exciting" doesn't necessarily mean "good", though!

All that stuff is hacked in, and that fact constantly reads it's head. So much that we are still debating solutions thirty years later.

And from using proper native frameworks for desktop applications.

It shows that web technologies were not designed to do what they do today.

back then I chose prism https://en.wikipedia.org/wiki/Mozilla_Prism because the user wanted a local app and I only wanted to work with the most ubiquitous UI. was lightweight and wish it was still available

Maybe it's about time to state that widgets-based GUIs are dead, time to switch to DocUIs, because that's essentially the point and the point is that WebApp today do much but are heavy monsters with very limited flexibility.

The current trend could be just ditch desktop environments just substituting them with a WebVM (the name "browsers" should have nowadays) instance. After a bit of time this model will explode, like the widget-based GUIs model, due to it's crappyness done only to disarm the user.

I kind of wish we’d have a popular alternative to Electron, based on the tech behind Firefox. That’d actually do a lot for the userbase.

How about no bloated webapps at all? Let's get back to developing reliable native applications.

I like the WAMR approach... utilize the portability of WASM but with a wrapper for writing desktop native apps with it.

Firefox lost that market a long time ago. Electron won because chromium is modular, the tech can be re-used for other purposes. Firefox lost because it's a monolith you can't use in your projects.

WPA's and webviews are non solutions. You can't have web sandboxing and also the privileges a desktop app needs. Wasm is a failed experiment that did not result in the performance improvements promised. You still need to compile C++ modules for all kinds of things.

I started evaluating electron and discovered that I would have to build messages for every single thing I wanted to do on the desktop and then tweak absolutely everything for performance. Not a great dev experience. I would much rather build a blazor app in a webview where I only have to send messages to the HTML for data binding. That shit is smooooth.

Reply on news.ycombinator.com