-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: access to menu bar and context menus #1025
Comments
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. |
@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 |
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 |
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. |
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 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:
[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. |
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.
The text was updated successfully, but these errors were encountered: