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

[david-rubino]

Hi everyone, my name is David Rubino and I’m a product manager for Firefox. As the Firefox leadership team mentioned in the Reddit AMA last week, we’re taking a fresh look at Progressive Web Apps (PWAs), which have long been a top request from our Mozilla Connect community. Today I want to share a concept that aims to address some of this feedback. 

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. 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), and by running web apps in the same session as normal browser tabs. I was a user of these features, and so when I joined the Firefox Product Management team last year, I decided to take a fresh look at how Firefox might approach the problem. 

In this post you will see that I don’t use the term “PWA” and instead stick with the more generic “web app”. While there are some working definitions for what a PWA is and is not, most of the feedback from the Firefox community are requests for specific capabilities. So when considering what Firefox should do, I’m focusing on how we can offer features that help you get a more app-like experience for any website you choose, when you choose. 

There are many specific requests in the thread, but viewed through this lens a few emerge:

1. Web apps should appear with their own icons alongside traditional apps, both in places where you launch apps and where running apps are shown. 
2. Web apps should remain open until you close them. You should not be able to “navigate away” from them like a web page.
3. Like many mobile apps, desktop web apps should be able to handle links to their website in lieu of having them opened in a normal browser window. 

It’s possible to take the web app concept further than is needed, into the realm of making web apps be as app-like as possible. This can make it seem like you’re not using a web browser or a website at all. Some examples of this might be having PWAs be installed and uninstalled using the OS, removing all or nearly-all of the browser “frame”, and limiting access to common browser features like bookmarks and search. While some of these may turn out to be beneficial, it’s not a goal to make it feel like you’re not in Firefox.

In fact, contrary to the notion that web apps should be “installed” like regular apps, a core idea of this concept is that running a web app should be thought of as moving a tab to your taskbar or dock... a one-step operation that can be undone just as easily. 

So what might this experience look like? Let’s look at the following topics:

1. Moving into and out of a web app “mode”
2. Offering a different browser UI for a web app
3. Browsing within and between sites
4. Integrating with the operating system

Moving into and out of a web app “mode”

As stated above, you should be able to take any tab and move it into web app mode in one step. When you take this action, the tab would be moved into a new web app window, maintaining the state of the web page entirely. You could even be watching a video, and it won’t miss a frame. There would be no setup. Each website will have some preferences associated with it, but the intent will be to have sensible defaults that work for most people, informed by a manifest if the site offers one. Moving a tab back out of this mode will be just as simple. 

Offering a different browser UI for a web app

Web apps are still websites in a web browser, so the goal will be to fully maintain access to features that help you with the website itself, while de emphasizing features that are about managing multiple websites. Some examples:

• No tabs or bookmarks bar by default, but these could be enabled in web app preferences
• The main toolbar would be fully enabled, including the address bar and extensions 
• A new toolbar section would show the icon of the website prominently, clearly indicating you’re in web app mode for a given site. This section would offer access to settings and controls for the web app.
• In lieu of a new tab button, there would be buttons to open a new tab in a normal Firefox window, or a new instance of the current web app. 
• The address bar would not be read-only, offering easy access to Firefox Suggest and the ability to search. Web pages opened from here would land in a new tab in a regular Firefox window. 

Browsing within and between sites

One of the key differences between a normal mode webpage and a web app is that you shouldn’t be able to “navigate away” from a web app. To exit a web app you have to explicitly close it. To accomplish this, each web app would be a “single site browser”. Navigations within the current website will remain in the app, and navigations outside the current website will open in a normal Firefox window. There will be exceptions to help with login flows and redirections so that a web app feels as much as possible like an app that only opens a browser when opening a truly external page. 

We would also introduce “link capture”, which would allow a web app to register itself to handle URLs within its scope. For example, if you click on a link to reddit.com in a normal Firefox window, the link would open in the Reddit web app. This behavior is analogous to how mobile browsers redirect links to registered mobile apps. 

Integrating with the operating system

On Windows, it is straightforward to show web apps separately on the taskbar using differentiated icons, to allow them to be pinned, to show them in the Start menu, in the ALT+TAB and window snap experience, and so on. This allows quick access to web apps using the same surfaces used to run or switch between regular apps. By “leveling up” to the taskbar websites you leave running and revisit often, you can save time over hunting for them in Firefox. 

This behavior may be more challenging to implement on macOS and is likely to have some limitations comparatively. You should expect that if we build a prototype, it will begin as a Windows-only feature. Once proven we would bring it to our other desktop platforms leveraging the features supported by them. 

Please let us know what you think!

I am hopeful Firefox can bring a web app experience to the desktop that will feel natural to all users, while supporting the needs of our power users. In particular, I think we can improve upon the current experience offered by other web browsers by offering one-step setup, retaining access to core browser features, and allowing links to be “captured” automatically. 

We are looking to make progress in this area soon, so I would love to get a discussion going about what is right and wrong and missing from this set of ideas. While I did read every post in the Ideas thread, I am aware I did not address every topic mentioned, so please especially bring up what I skipped that is important to you. 

Thanks in advance!

-David Rubino
Product Manager
Mozilla Firefox

[jscher2000]

Hi David, I think that will be useful. I had three thoughts while reading this:

(1) The site-dedicated behavior of the single-document web app window sounds similar to a pinned tab, which makes sense considering that pinned tabs were originally called app tabs.

I think it would make sense to enhance the functionality of pinned tabs in parallel with the web app windows to minimize unnecessary differences. You might also want to allow a user the ability to move a web app window to a pinned tab in a regular window, and vice versa, to move a pinned tab to a web app window. And it may make sense to treat the two the same for session restore purposes.

(2) If I capture links and dedicate them to the web app window, I may be annoyed by losing my place rather than having a new tab open.

Could the captured links be queued for user action to display rather than triggering immediate navigation? Perhaps this could be managed with a toolbar button list or a sidebar.

(3) Enabling the address bar and main toolbar would address complaints about extensions not operating as expected in the PWA prototype. I hope the team will consider whether to make the same features operable in feature-specified pop-up windows for consistency.

(For reference, I mean the type of window opened by the third link here: https://www.jeffersonscher.com/res/popit.html)

[david-rubino]

Hello Jefferson, and thanks for taking a look at this! Sorry it took me so long to circle back.

First about pinned tabs... I've already got a Jira ticket in the backlog for updating pinned tabs to keep them in sync with what we do with web apps. To start I have two things in that ticket:

1. Keep the pinned tab scoped to the current site even if you use the address bar, bookmark, etc. to navigate.

2. Add link capture as an option for pinned tabs

Let me know if there are other specific ideas you have here.

Second, moving tabs... the current notion is to allow users to move tabs using drag/drop and menu options, subject to rules about scope. So you could always move a tab from a web app window to a normal window, but you could only move a tab from a normal window to a web app window if the tab matched the scope of the web app window. Moving a tab from a web app window to a new window would create a second window for the web app.

I love the idea of integrate with pinned tabs as well / instead. For one, it makes total sense to create a web app window if you drag a pinned tab to its own window. I've added that to the ticket. I'm a little less certain about the other direction... my inclination is that a web app tab dragged into a normal window should become a pinned tab only as a user option, or if the web app originated as a pinned tab in the first place. What do you think?

Third, the "link capture may feel disruptive" problem. I agree that it could. For now I'm comfortable with link capture being on or off for a given site, but it could make sense to an an option to "ask" or "queue". I added a ticket for that to the backlog.

Finally, about access to address bar and extensions on regular popup windows. To be honest, I don't know the history here and I don't own this... I'll have to ask internally. I do see 1849495: "Add-on buttons don't appear in popup windows". The suggested solution of adding just the extension button makes sense to me... it keeps the "minimal window minimal" as Tooru says in the bug. As for making the address bar editable, I don't see a suggestion in Bugzilla for that (I could be missing it). Would you be comfortable filing one with type = enhancement, product = Firefox, and component = address bar? If not I can...

[suikaz]

regarding links to the outside of the app: make sure to pass them to the OS, don't keep them trapped inside of one browser

user is allowed to choose the default handler however they like and one of the big issues with Chromium PWA is the fact they keep navigation trapped and external links open in the PWA browser instead of the default handler

another issue I have related to that comes from Fenix: when you tap external link in it it opens custom tab "within" PWA instead of passing it through the OS and I'd love that changed

also it feels like Fenix has a special list of apps that can be run in PWA mode and all others only do a shortcut pin, even when they work in Chromium browsers

[david-rubino]

Thanks for looking at this with me, and sorry for the slow reply.

First, about passing links to the OS... my expertise is Windows, and I'm not aware of a way in Windows to associate a URL domain with a handler. For example, I don't think I can install the Netflix app on Windows, and then have Windows send all links to netflix.com to the Netflix app. Am I wrong on Windows? Much less familiar with macOS and Linux. Is this possible there? In any case, if any of the desktop OS platforms do support this, let me know and I'll poke at it more.

Regarding the special mode on Android for handling external links, that sounds like fair feedback. Desktop Chrome and Edge do something similar, and I am personally not a fan. Would you be comfortable logging this to Bugzilla as type=enhancement, product=fenix, and component=PWA? If not, I can log it for you.

As for the "special list" of apps which Fenix installs as a PWA versus a shortcut, I believe the distinction is that only websites which provide a PWA manifest are installed as PWAs. I certainly understand the suggestion to change this as well, and I'd ask you to open a bug on that as well (or ask me to).

Thanks! -David

[suikaz]

I'm pretty sure per domain handlers are available since win8, but the app has to be specifically listed as allowed by the website (probably dev mode apps are extempted from that or this requirement is enforced by the store itselt, not the OS)

but my main issue was: if I create PWA in Edge *all HTTP/HTTPS* links are trappped and whatever I click opens in Edge, I'd like external links going outside the PWA to be passed to the system to keep the user in control, if they want different default handler for http and https that should be respected

I can add the ticket in bugzilla myself, just have to remember about it when I'm at my PC

do you know about any extra requirements to pin PWA on Fenix? I can't get my app to do so while Chromium does it as expected

[david-rubino]

Ahh I see! Funny story... when I first started working at Mozilla, I was an Edge PWA user and I had to write myself an extension (for Edge) to solve this exact problem!

While I'm completely onboard with the user being in control, I know from experience that a lot of users aren't as in control of their own default browser as we might hope they are. I think linking out of Firefox and into a different browser is probably best available as an option in Firefox rather than the default. I've logged the suggestion. (And feel free to DM me if you want to chat about a Chromium extension that relays clicks from PWAs to the OS default browser)

I'll see if I can get you some support for PWAs on Fenix.

-David

[suikaz]

maybe you are right, but if we're talking about people with less control and experience... keeping the default as staying inside but also showing some call to action the first time (or until they decide to dismiss it permanently) letting them know they can easily switch it to a default handler may be useful

people tend to never visit settings and would rather complain and abandon a good product that has defaults they don't like than finetune it so letting them know they can may be useful

[david-rubino]

An internal expert on PWAs for Firefox on Android looked into this a bit, and filed this bug:

1906681: "Install menu not available when PWA is detected". If you think this is your bug, then let me know. If you think it's something else... can you share your site (a DM is fine if you wish) and we'll take a look at how it's handled?

Thanks,

-David

[suikaz]

this seems like it may be the same issue, hard to tell without debugging further, but the symptoms would check out

[jonalmeida]

Hi @suikaz ,

I had a look at your PWA that David sent over and it looks like you're missing the 'icon' requirement for a web app manifest. You can see the list of required members here: https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/Making_PWAs_installable#req...

That said, we could probably do better in Fenix by trying to grab the favicon or generate one for the web app if it isn't provided. I think that's a fairly straight-forward expectation and what I see Chrome doing.

I've filed bug 1907469 to add this new case.

Thanks for the feedback here!

[suikaz]

thanks, I *think* I've tried having icons too, but maybe some specific size is required and I missed that? but now I at least know what to look for, I'll try adding some placeholders when I have some time

thank you again

[suikaz]

thank you again, I got it working! but now I discovered another issue that might've been expected but surely I haven't anticipated this:

when open as a PWA Fenix changes the context menu of links a lot, presenting only share and copy address, it would probably be nice to add open in a browser (and if even possible on Android open in a browser in background), that would help the custom tab issue I mentioned in another comment and would make my life easier as a bonus

[jonalmeida]

That sounds quite fair. Could you file a feature request here or if you're unable to, let me know and I'd be happy to file one on your behalf: https://bugzilla.mozilla.org/enter_bug.cgi?product=Fenix&component=PWA&bug_type=enhancement

[findorf]

On linux custom schemes can be configured to open with certain apps by setting the default app to open with the  `x-scheme-handler/*` mime types.

See https://specifications.freedesktop.org/shared-mime-info-spec/0.22/ar01s02.html#id-1.3.18

I'm not sure if there is a way to specify that certain domains should be opened by a specific app.

Unfortunately, the application either needs to parse the mime app files itself (or use a library such as Gtk or Qt), or shell out to another program that does, like `xdg-mime` or `xdg-open`.

[dannycolin]

---

Offering a different browser UI for a web app

---

Would it also support Container Tabs? For example, I regularly use 2 separated gmail accounts that I open in a different container so I can have them open side-by-side instead of switching accounts in gmail itself. With Webapp Mode, I'd still want to retain the ability to have two separated single-tab browser.

[david-rubino]

Yes, I'd like to see this, and I have a backlog placeholder Jira ticket that just says "Container integration". How do you think it should work? Some ideas:

1. Certainly when a tab is moved to its own app window, if that tab has affinity to a container, the web app should remember that affinity on subsequent launches.
2. Seems like a container could also uniquely define a web app... so it would be OK for two web apps to have identical scopes as long as they had different containers. In this model, your two Gmail tabs would become different apps, each pinned separately.
3. Or perhaps, it would be better for a single app to support multiple containers. In this case, launching the app would launch two windows, each which shares an icon, but the tab in each of the two windows would have a different container.
4. To make this make sense, a web app window would probably need to have an affordance to simply create a new container which shares the same home page. Honestly, we'd want to describe it as something like "log into this app as a different user", rather than using anything like the current container UX.

What do you think? What am I missing?

-David

[Blisterexe]

Not op, but the way i see it option 2 is the best one.

Like, when you create a webapp, it asks you the website and what container it should be in.

The webapp then always opens in that container, two webapps from the same site but different containers are differenciated by a little icon in the corner of the icon, kind of like how ios shows what app a messaging app notification comes from (pic related)

 

[Oneeyedziggy]

I'm working on a PWA now and would love to be able to send notifications without involving a server... It's nuts that the current APIs seemingly require a server to trigger the push notification api to wake the app to send a notification...

Also silly you can't really schedule notifications, just setTimeouts and write a custom system to manage and interrupt/re-schedule them if you don't just want a potentially unlimited number of long-running setTimeouts... But that seems like the only option for the time being

[david-rubino]

Hey, this is interesting... I know a little bit about how this works, but not a lot. Help me understand.

I'm aware of the Notification API... showing a notification like so:

const notification = new Notification("Hi there!", {
   body: "This is a notification.",
   icon: "icon.png" // Optional icon
});

I don't think this requires a server. Does this work for your scenario? I assume not otherwise you wouldn't be posting this... so help me understand what about it doesn't work.

(By the by, I'm completely aware that there are 100 experts I work with that can answer this too... but I'm just not one of them... thanks in advance for helping me learn)

-David

-David

[suikaz]

I think the point was to schedule the notification without having to keep the script running, something more akin to WebExtensions alarms that are events handled by the browser, not by the in-page timer

[david-rubino]

Makes sense. I don't know the answer here. I will have to consult internally and find someone or somewhere to get support.

[jonalmeida]

The difficulty here is that mobile browsers are still just apps which can be killed by the user and/or OS. Long running in the background increases the chances of the app being killed by the OS more often on devices, which makes it important to not do unnecessary background work when we can avoid it. Building something that lets the app "wake up" and check what javascript wants to run is non-trivial.

WebPush + WebNotification allows the web app developer do this kind of "wake up" because they would know best when their message needs to be run.

There also isn't a good web API that lets you do what you want as a good citizen, without it being abused by other web apps, so all browsers typically try to reduce what you can do with notifications.

This isn't the most satisfying answer unfortunately, but I hope that helps give you some context on the difficulty behind it.

[amanitamc]

What is a "lieu"? Please use simpler speech I never heard that word in my life.

[00FF00]

basically it just means alternatively, or instead of. which fun fact, TIL where the word instead comes from

>Like many mobile apps, desktop web apps should be able to handle links to their website in lieu of having them opened in a normal browser window.

so that is basically saying "desktop web apps should be able to handle links to their website [as opposed to / alternatively to / instead of/ rather than] a normal browser window.

in other, other words, "desktop web apps should handle links to their website inside the PWA/web-app and not open in a normal browser window"

[david-rubino]

Apologies. It's just a different way of saying "instead of".

[RabN]

I'm sure that you have already taken a look at the PWAs for Firefox addon. It accomplishes most if what you describe for the end user. Their implementation allows web apps to run in their own "containers," which is helpful, but could be improved. Web apps should be able to use addons if desired, which should be customizable for each app.

Apps should have the ability to open links in the default browser if chosen.

I love that you will plan to use an implementation that will allow for any site to be installed as an app. That is a key feature because many sites that are designed as apps may not be set up as PWAs.

An address bar in a web app makes no sense me. Having it available in a menu or behind a click is understandable, but I would like to use a webapp as a standalone app as much as possible, not waste screen real estate on browser elements. If an app is well designed, there should never be a need to interact with an address bar or other browser elements (with the likely exception of the back navigation). PWAs for Firefox handles this very well.

Web apps should be easy to manage through a settings menu. I should be able to add or delete an app from a list, as well as adjust individual settings, such as whether it is running in an individual container or one of my existing containers, which addons are active in the app, permissions like camera and mic, and ideally even options like changing the default zoom and text size, or toggling hardware acceleration. I've found it is also essential to be able to change the icon manually.

Others may find it useful to combine/merge webapps into a browser window as tabs, but such a feature has no value to me. As much as possible, a web app should behave as an installed app, with the browser acting as a backbone, and as invisible as possible.

It's a small thing, but a web app window should open in the same state and size/aspect that it was last closed.

That's my wishlist and suggestions. Some of it may run counter to the direction you are headed, but I hope you'll be able to implement as much as possible. This is a big leap in the right direction! Thank you for the work you do.

[david-rubino]

Thanks so much for taking the time to weigh in here. I'll try to address everything quickly.

Running web apps in their own containers

This isn't what I was thinking as a default. With "total cookie protection" I'm not sure containers have a lot of utility outside of having more than one of them for one website (to manage multiple logins, or to be able to see both a logged-in state and not-logged-in state at the same time). I would like to support these scenarios (see my response above) but anything beyond that I would need some additional perspective on. If you think there's something I not considering, please let me know.

Use addons if desired...

Absolutely, and comes for "free" in the current idea.

...customizable for each app

What kind of customization are you looking for?

Open links in the default browser

So do you mean... even if the default browser isn't Firefox? If so, I'd be curious to hear about the use case. If you just mean "in Firefox" then OK, which of the following is the closest to what you mean?

a) Links from example.com to another page in example.com stay insider the app, and links from example.com to external.com open in Firefox

b) A user can right click on a link from example.com to another page on example.com, and choose "Open in Firefox"... thus overriding the default handling

c) A web app can target any link at a normal Firefox window by specifying something like target=browser in the markup.

Web apps shouldn't have an address bar

You won't be the only one who is thinking this! I completely understand. Here's my reasoning:

• An address bar is needed in order to see where you are, which can be important for security/safety online.
• The address bar element contains a bunch of controls, from site settings to page action buttons for extensions, to simple copy and paste, that are generally still relevant in a web app. We could recreate these functions in a new UI... but that's a heavy lift compared to just displaying the address bar we already have.
• Once it's there, having it be read-only is frustrating. For one, people do edit URLs in a way that doesn't navigate away from a site. And for those URLs that don't, I think we can make it clear in some way visually that following them will open a Firefox window.

I like options though, so I have recorded the request to turn this off in a Jira ticket.

Managing settings

Yes, having a list of installed apps seems basic to me. I could imagine testing out some concepts without building this, but anything beyond that would need a management UI. As for particular settings... see my previous questions on containers and addons... and then I have other questions:

a) Text size and hardware acceleration are very rarely changed settings. Why do you think these are useful?

b) What's the situation in which you would want to customize the icon? Generally a browser's job is to present a website in the way intended by its creators. For that reason, I'm hesitant to offer this.

Save zoom, window size, and window position

Yep, makes sense to me. Added to Jira ticket.

Feel as much like an app as possible

Well, as you saw in my post I have a different hypothesis... I'm inclined toward making it feel like web apps are just tabs that have been moved to your taskbar/dock and can be moved back. I think more users will understand this. However... if we do this right you'll be a few settings changes away from being able to think of these like truly separate apps. I'll keep this post (and others I'm sure will follow it) in mind as we move forward so we don't move past the point where you will find this suitable.

Thanks again! -David

[suikaz]

passing external.com to the default handler has multiple use cases:

someone may be using one browser for PWA and another as a default due to the differences between their capabilities

in my case I use Browser Router as a default handler and it passes the link further based on different rules, it may pass it to an app that can't be set as a default handler, it may pass it to a different profile, it may pass it to a different browser

but the most important thing is making it seamless: if a webapp is meant to behave like an app it needs to behave like an app and pass links to the default handler, that's what people expect

[david-rubino]

OK, understood. See my reply elsewhere. I think the case is quite valid and have filed this in our system.

[BiORNADE]

What kind of customization are you looking for?

I'm just here to complement (not what RabN is thinking of), but there's one feature missing in almost every single browser; which is the option to be able to change the icon, if the program will run when starting the computer, if allowing extensions or not, etc. (kinda like some of what Rayke  described)
Here's a mspaint edit I made in 5 minutes to demonstrate my 2 navbar ideas:

It's true that some divisions might happen if everything just happens to be the same interface...
~~Like, if you use the same interface for ALL webapps, including "PWA Powered" ones (native PWA support), it wouldn't look great:~~

EDIT: This part aged faster than milk; it actually looks good than what I thought originally.

I guess some more simple appearance like this would make the PWA Powered apps look better, despite it kinda challenge the Firefox feel/looking:

Consider this as a grain of salt; tho it looks more of a Undistractive mode than the one made above, but that might not be what RabN is looking for

An address bar is needed in order to see where you are, which can be important for security/safety online.

Make the name of the Window name show up a similar box from the image when hovering for 2 seconds:

Also, you can recycle the Sidebar codes to open certain websites externally; besides, no other browser prompts to change the URL, and I have never of a concern about that (but maybe when double clicking, as a feature) 

We could recreate these functions in a new UI... but that's a heavy lift compared to just displaying the address bar we already have.

Many of the elements can be reused; instead of developing many new icons and such, you can directly take the Firefox icons and (mostly) reuse them for the page UI too, making it compatible with CSS themes! Well... Just in theory, as some elements would look way better when modified slightly.
For the title, just use the one from the main page or just the title. If it is PWA Powered,
Correct me if I'm wrong, but I would guess the theme itself would take about 450KB or less.

[david-rubino]

Hello! There's a lot to parse here... want to make sure I got it right

There should be an option to change the icon

I'm hesitant about this... seems like a vector for fooling people into thinking one site is another. My instinct is to honor the icon provided by the website. A website can provide such a choice though.

Provide an option to set an app to run when the OS starts up

Yes, this seems righteous. I added it to our backlog of ideas.

Provide an option to disable extensions for a given web app

Probably this should be fine grained control to turn an extension off on a per web app basis, and probably coupled with web app specific toolbar button pinning. Added a tracking ticket for this.

Make sure the PWA window looks distinct (and looks good)

Thanks for the concepts. I'll have our designers look at these. Regardless, yes it's very important that the window is visually recognizable as being a web app window. I will say though, because this will only catch on if all kinds of users use it (think, my mother... rather than people like us who spend time on the forums of a software product) it will also need to feel like a Firefox window, a web browser window. It will be tough balance, and the purists among us will be dissatisfied at first. Remember though, the broader the adoption the more we'll get to build in niche customizations later.

The window shouldn't have an address bar

Your vote on this is noted. I know it won't be popular here necessarily, but I think it's part of the broad adoption I mentioned above.

[kjintar]

Regarding the icon:

I've already arrived at the point at which I wanted to change the icon of a PWA. However, I'm convinced that this should be handled either by user configuration on the OS level or by providing such configuration within the app. I share the concerns you mention.

There's already a trend for in-app customization options for app icons on mobile. I believe that such customization options are fair monetization options for app developers. Providing such options at the browser level would be nice for end users—no doubt—but would also decrease the value of these in-app options.

There are also options on several systems to customize app icons at the OS level already. The latest iOS update introduced tints and other low-impact customizations. On Windows, you can change an app's icon in the taskbar and on the Start menu by creating your own link and setting an individual icon. (This option is currently flaky for PWAs since some implementations update/recreate the links, causing the manually set icon to reset.)

There is a demand for app icon customization, but I personally do not believe that browsers are the expected level to solve the issue. However, you should provide a seamless mechanism to allow apps to update their icon on request and may implement future standards defined by OS providers.

Regarding Extensions and Profile Settings:

I'm having my thoughts about browser specific settings in the PWA context as a whole. I dislike having entirely sperated profiles per PWA, but I also dislike having the same profile linked to all PWAs at the same time. Even setting a profile per app is (even though it should be possible for power users) probably too complex for everyday users.

Which leads me to a concept of some kind of override mechanic for PWAs for all profile related settings except Firefox Sync. That would include a new UI component for frequently modified settings and an extended UI to edit further settings. I might aim a bit high here, but that's what I would like to see.

[RabN]

Thanks for the comments! Control of containers is useful to me mostly due to logins. Say, for example, a user wants to use Gmail from one account and watch YouTube from another account (or none). It doesn't necessarily need to launch by default in a "new" container when created, but one of the perks of running them as webapps is that they are kept separate from my browsing activity in that sense. OTOH, some users may want all of their accounts connected across apps?

Glad that the addons are already in process! By customizable, I mean that say for example I use Dark Reader to ease the eyestrain on some sites, but on a particular app I don't want it; or say that my adblocker interferes with a certain webapp. Or I have a YouTube addon that I only want to use when it is in the app. The ability to set which addons are active in a per-app basis would be helpful. I may want them to behave differently than my browser.

For links I meant situation "a". Although some people do use multiple browsers. For a long time I had FF as my default browser but ran webapps through Edge. I would have liked those links to open in my default instead of in Edge 😉

Many websites have bad, outdated favicons, and they are not always well-suited to resizing. If I have an app pinned to my menu bar to stare at all day long, I don't want to look at pixelated garbo. So I often change them through the OS - that's just my personal experience. However, I do understand your point about the responsibility between browser and site creator.

Yes, a basic UI, like a Settings page/tab is exactly what I would hope for in a perfect world. As for some of the options I mentioned, some sites have small fonts and a user may want them bigger, or I might have an app that I typically share in video meetings and want the font to be larger and more readable for sharing. I'm don't personally have a use, but some people use webapps to run games or graphics editors and may want options like acceleration only in those cases. These are admittedly niche, but may help to differentiate this from other browsers (as long as we are re-imagining what a webapp could be).

Thanks again for listening so thoughtfully to comments from the community! We really appreciate the work you are doing... even if we can get a little "passionate" at times!

[david-rubino]

Containers

OK... got it. So what I'm going to write down is the ability to assign a web app to its own container or a container of choice. That way you could install two GMail apps for different addresses, or a GMail and a Youtube that use different credentials. The reason I don't want container isolation by default is the inverse case... if I have one Google login and I use it on many sites, some of which are web apps and some of which are not, I want the login state to be shared.

Add-ons

OK, I am tracking the per-addon per-web-app configuration in our roadmap now.

Open in default browser

Well yeah... I have the exact same story as you! I used to work on Edge, and now I work on Firefox. When I first came to Firefox, since it didn't support web apps, I continued to use Edge for the web apps, but wrote an extension to launch external links to Firefox. Obviously I have some bias toward not implementing a Firefox feature to launch another browser, but I understand the user choice behind the idea and I will track it for consideration.

Icon customization

Low quality icons... I get that. I will track it for consideration.

Settings UI per web app

Absolutely. Don't even need to track it.

[00FF00]

i use PWA's quite a bit via edge currently, for certain websites, but would definitely use them in firefox instead of edge if it was implemented. i guess the thing i would like is the ease of setup like edge has where its basically a one click step, and since im always focused on the cosmetic differences of websites lol maybe have a way for each installed webapp to have a simple setup for using its own font and website color layout, along with if it does have a toolbar (which i think it should have some kind of toolbar, just no url bar) allowing a different theme to be set, maybe using the firefox colors theme builder add on? i guess im not sure how complicated that all would be - but it would be neat!

i guess at that point it would almost be like having multiple installations of firefox, like i have the regular version and then another version, and they each have different website color/font layouts and different themes

also from the discussion thread on reddit sharing this post:

>from u/feelspeaceman: Here we go PWA, it's pretty nice to have as someone who regularly using Floorp's PWA, having web app pinning in Taskbar can be lifesaver, for example pinning Weather App, World Clock App or Photopea, it's really helpful and it improves my workflow.

>from u/oneeyedziggy: Working on a PWA now and would love offline scheduled notifications to be more possible... Its absurd that the current apis basically preclude something as simple as an alarm app or anything with scheduled reminders without a server sending push notifications ( i think... I'm also still working around the rediculous state of the notification API on Android vs desktop )

[david-rubino]

Thanks for taking a look at this! I love the idea of per-window themes, and I've added it to the list. In the meantime, applying a color tint to the window automatically (based on the icon perhaps) might be something we can do even earlier

-David

[Rayke]

In Firefox I use Javascript bookmarks which open the pages I wan't to act like PWAs as popups. This gives me almost everything I want in a PWA.

When I click a link in the popup it opens the link in a new tab in the main browser instance. The URL is immutable and acts like a title bar for me so that I can see the domain.

As a Sway WM user the main thing that I want is a constant, predictable appid/class-instance that is always the same for every launch of a window through it's entire lifetime which is what Chromium based PWAs have.

I imagine that would probably be nescessary anyway if you want to implement custom icons under linux since that would probably be tied to the window class.

I use those unique properties to automatically move windows to a specific workspace on my 3-monitor setup and it greatly reduces the amount of window management I have to manually attend to.

I have a workaround for Firefox but it is not elegant and requires a bash script running in the background to detect the windows and watch for my specific title that I provided in my javascript bookmark.

The other things follow what everyone else wants, mainly to be able to launch the PWA from my desktop environment instead of having to do it from Firefox.

I build nightly myself and have been enjoying the new functionality including the new sidebar tabs. This is even more exciting, it would make my year.

[david-rubino]

Thanks for weighing in. The level of customization you're describing is impressive. Linux is currently not in my wheelhouse, but I've started a Jira ticket recording this and what I assume will be other thoughts about Linux.

For your existing solution, do you need the appid / class-instance to be static just for the lifetime of the window? Or every time a given site is launched? Either way, I'm wondering if it isn't something you could manage with a privileged extension. Since you're a dedicated Nightly user, you can write such extensions for your own use.

[Rayke]

I need the appid/class-instance to always be the same.  If you look at how a Chromium PWA works, the window gets an app_id (Wayland)/class-instance(X11) that is generated per manifest when the PWA is installed.  The window will forever be identified by that generated value and will be the same even if I uninstall the PWA and re-install it.  It is probably a hash or something involving the domain name.

For Example.  If I install Fosstodon as a PWA using Chrome the identifiers are:

For Chrome started with Wayland support:
app_id="chrome-dkoiajbhajakglgcmkbhmcphnoiempab-Default"

For X11
class="Google-chrome-unstable" instance="crx_dkoiajbhajakglgcmkbhmcphnoiempab"

As for handling it with a privileged extension, I am not sure how that would work (I have never heard of a "privileged" extension) or if it would be better than what I currently have.  I wrote a local extension that creates the JavaScript Bookmarks based on the domain name only so that Sway at some point sees a fixed name even if it is changed later in the window's lifetime.  (e.g. fosstodon.org would briefly have a title of "fosstodon-org" when the popup is opened).  I then monitor a socket with bash that runs in the background watching for a window title "fosstodon-org".  Once it is seen, the bash script moves it to the appropriate workspace.  The main issue is that since the window starts off just being called "Firefox Nightly".  It briefly flashes and resizes the windows on my current workspace until it is changed to "fosstodon-org" by my bookmark JavaScript. My bash script then sees it and performs the operations on it, causing the original workspace to redraw and resize the windows on it again, since the popup window has been moved.  For Chrome PWAs I see the unique ID before the window is even created, so the window can be initially drawn on the correct workspace without needing to be moved by my script since I can use a regular Sway window rule for that.