Support Chrome web apps on Mac #1844
Conversation
Chrome web apps (created by choosing "Install this app" from the URL bar or overflow menu) appear on macOS as com.google.Chrome.app.[a-z]+ (https://developer.chrome.com/docs/capabilities/pwa-manifest-id). Currently, 'com.google.Chrome' is not broad enough to identify a web app as being a valid Chrome window.
|
Do those apps really behave like a browser in that they have tabs and a URL bar? That strikes me as odd, not sure why you'd install such an app then. |
|
Yes and no. The "apps" are just a Chrome window that doesn't have all of the extra decorations like a tab bar. I see what you mean and you're right that they don't behave entirely like a normal browser window, but they are effectively a Chrome window. On both macOS and Windows if you open a Gmail tab, Calendar tab, Github tab, etc, and you want to be able to jump back to it quickly, you could leave it in a separate window, or just pin the tab, but pulling it up again isn't as easy as activating an icon docked in your system tray / dock. When you "install" a page via Chrome (which creates these "apps"), you're giving that website a unique identification in your sea of browser windows and tabs, allowing you to dock it to your tray if you want. If you have 15 Chrome windows open, each with 50 tabs, docking one of these "apps" is a handy way to be able to access it quickly without needing additional shortcuts. The problem I'm trying to fix is that talon command sets that are keyed on the browser tag don't work inside of these web apps because they're not being identified as a browser. The specific use case is Rango. Rango can hint the page as if it's a normal webpage (which it is), but when you try to issue a Rango command you'll end up with typical talon bad-command suggestions instead of it recognizing the commands as valid commands for Rango. I suppose an alternative way to fix this would be to add additional identifiers into Rango's config instead but it seems like this would be something I would expect others to have run into with other commands - or am I really the only one that uses chrome web apps / progressive web apps? I didn't test on Linux, but I did test it on Windows and it doesn't appear to be an issue there. The web apps are presented in such a way that they're identified as being Chrome windows. |
|
I also use web apps for access to Rango (and the greatly improved accessibility in Edge / Safari vs electron apps). Works great with many apps such as teams, discord, one note, and a bunch of others. This is worth putting thru some paces imo |
|
From the community backlog session — we agree that this is a useful thing to pursue. The main issues we noticed with experimenting with Edge and Safari were:
So I think we should decide whether we want to have a separate tag "user.browser_webapp" or similar, or just want to allow for the fact that some of the actions that would otherwise work in the host browser would not work in a webapp. Thoughts? |
|
Is there a performance or user experience cost to accepting that some browser commands won't work in these web apps? If we take the alternative route and create something like "user.browser_webapp", it would need to be applied to an unknown and potentially unlimited number of web apps. At least in Chrome, any web page can be turned into a web app. Most people are probably not going to turn a random one-off page into a web app, but the potential for any page to be a web app means the tag would need to be applied to any browser based service that could potentially be made into a web app. |
Chrome web apps (created by choosing "Install this app" from the URL bar or overflow menu) appear on macOS as com.google.Chrome.app.[a-z]+ (https://developer.chrome.com/docs/capabilities/pwa-manifest-id). Currently, 'com.google.Chrome' is not broad enough to identify a web app as being a valid Chrome window.