Open flachware opened 2 years ago
This feature can make PWA more like a native application, and web developers can provide powerful PWA with more capabilities. Our team is also considering this feature. However, it is not flexible enough by the manifest attribute. I think it's better to implement it through web API.
@flachware Could you expand on this request with specific use cases? That can help us with determining how to best go about it. The menu bar piece could dovetail nicely with shortcuts
(which are similar), but they are static only right now (though we have discussed adding an API for shortcuts too). There is also an HTML menu
element that could be used to provide context menu options and the now deprecated menuitem
and contextmenu
.
Sure: the workflow of the specific application I am working on (a knowledge organization tool) simply relies on the app menu and context menus. I think this is true for a lot of document-based tools, where you have 'Open', 'Save', 'Save As…', 'Import', 'Export', etc. in the 'File' menu. Plus other commands that are in good hands in a structured app menu. And context menus provide the required actions in place where you need them.
Of course it can be worked around these issues with custom solutions, but my request is explicitly about accessing the native menus in order to integrate PWAs better into the OS and let users work with them the same way they would with any other native app (and in terms of accessibility it could be a real annoyance if the actual app menu is not where you expect it). Pragmatically speaking: there are already app and context menus – let’s use them! It would be a pity if PWAs had to rely on redundant custom menus while the native app menu stays unused. As for the context menus, I deem it to be a matter of consistency, which means the more native features we can use, the better.
If the manifest itself is not the right place I apologize for bringing this up here, I assumed some kind of new API would be needed for this feature(s), but I did not rule out the possibility that at least some parts of the menus would be configured in the manifest, hence I made my point here.
As an example of a use case for this, my app SVGcode uses Window Controls Overlay to get a top menu that feels fine on Windows or Linux, but on macOS, I'd rather move this menu up to the actual macOS menu bar.
Personally, I'd prefer to have this as a (separate) dynamic API, similar to Electron's Menu.setApplicationMenu()
rather than adding menu entries as static properties to the manifest.
but I did not rule out the possibility that at least some parts of the menus would be configured in the manifest
Agree with this. The default customized menu could configured in the manifest, and the customized menu for some special pages or operations could dynamic configure with API.
I’m fine with either. One detail to think about is wether or not PWAs should be allowed to change the app menu while the PWA has not been installed yet. Personally I think it would be strange if the app menu of my browser changed while browsing.
One detail to think about is wether or not PWAs should be allowed to change the app menu while the PWA has not been installed yet.
I feel like this is something that might need to be gated on installation.
I agree with this request. All the apps based on broswer need it. Like Figma, Fusion 360, ……
FWIW, I have started brainstorming on an App Menu API for installed PWAs in https://crbug.com/1295253.
@Thomas I added some comments there. Happy to contribute to an explainer if you would like a partner.
I created https://crbug.com/1334323 for os context menus, independent of the window etc
Well, this issue's already open, i want to know wheather this feature has risk? for example, web customer believe the native browser code, but the website could execute some actions themselves.
@xkol Late reply but this could be malicious, let's say you're an not acquainted to technology, so you see an install button on the safety of the web (You might be inclined to the think that the internet is a safe place) and you decide to click on it, low and behold you have install malware! The malware takes use of wasm and starts mining x whenever you open the site, and they have just decided to create a context menu named "Delete", "Copy", "Paste", "Share", and "Help", all of them lead to your malicious program
So yes this does have malicious intent, but if you were to have a checklist whenever they install an app to make sure they want the certain context menus, Ex:
⚠️ Warning ⚠️ Apps may pretend to be trustworthy applications in order to ...
[Confirm?]
But this can easily be done with a malicious .exe (So, there would still be risks, but the risks are already presented if you have context menu items in your os by default)
@xkol Late reply but this could be malicious, let's say you're an not acquainted to technology, so you see an install button on the safety of the web (You might be inclined to the think that the internet is a safe place) and you decide to click on it, low and behold you have install malware! The malware takes use of wasm and starts mining x whenever you open the site, and they have just decided to create a context menu named "Delete", "Copy", "Paste", "Share", and "Help", all of them lead to your malicious program
So yes this does have malicious intent, but if you were to have a checklist whenever they install an app to make sure they want the certain context menus, Ex:
⚠️ Warning ⚠️ Apps may pretend to be trustworthy applications in order to ...
- [x] Add "delete" context menu to your os?
- [x] Add "copy" context menu to your os?
- [ ] Remove All
[Confirm?]
But this can easily be done with a malicious .exe (So, there would still be risks, but the risks are already presented if you have context menu items in your os by default)
The proposal, as I understand it at least, would be to augment the menus only in the context of the app, not globally. So those menu items would only appear when the app is active and in the foreground, when the user is actively engaged with it. They would not be finally available within the OS.
Your other concerns are general critiques of PWAs and apply equally to the Web writ large (as well as extensions). Addressing them is more the purview of malicious website scanners/mitigation (e.g., SiteScanner, etc.) within the browser and/or OS.
The proposal, as I understand it at least, would be to augment the menus only in the context of the app, not globally.
Yes, that was the idea.
I'm also interested in this feature.
Allow desktop PWAs to add entries to the native menu bar and native context menus.