Closed
Bug 775962
Opened 12 years ago
Closed 9 years ago
Custom window menus for WebApps
Categories
(Firefox Graveyard :: Web Apps, enhancement, P2)
Firefox Graveyard
Web Apps
Tracking
(firefox16 wontfix)
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox16 | --- | wontfix |
People
(Reporter: marco, Unassigned)
References
Details
This would be a great feature for a lot of applications (office applications like LucidChart, for example).
https://wiki.mozilla.org/Apps/Menus
Updated•12 years ago
|
Severity: normal → enhancement
Updated•12 years ago
|
Priority: -- → P2
Updated•12 years ago
|
status-firefox16:
--- → wontfix
Comment 1•11 years ago
|
||
Just adding some context here for this specific proposed feature. The menu element that is referenced in the above comment (https://wiki.mozilla.org/Apps/Menus) as far as I can tell was last discussed here: http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Dec/0264.html but since hasn't had a lot of progress. It seems only Firefox has limited support and that related to the context menu part rather than the toolbar part http://caniuse.com/#feat=menu.
CC'ing Jonas on this bug to get a little background on the menu tag as you were on the original whatwg thread. If there is forward progress, I think this declarative interface should work well enough across windows/mac/linux in terms of the runtime implementing support for native menus, and if other browsers are intending to implement this all the better in terms of cross compat. Would love to hear your current thinking on this.
As an alternative if things are stalled on this initiative, we could potentially expose a JS based interface in the interim similar to the way Sencha Desktop Packager does it, i.e.
http://docs.sencha.com/desktop-packager/1.2/#!/guide/tutorial and for the full api ref here: http://docs-devel.sencha.com/desktop-packager/1.2/#!/api/Ion.ui.Menu
Some advantages that I see with it being scriptable initially is learning how people typically use it and having finer grain control over the separator placements, and some events around the state of the menu, i.e. aboutToShow() and aboutToHide().
First off, the spec has as far as I can tell received very little attention from other browser vendors. So we should not think of what's in the spec as a vetted solution but rather as a proposal from the spec editor. If we think that we have better ideas for how to do this, then that's what we should prototype.
I do like the draft at https://wiki.mozilla.org/Apps/Menus
I'd probably recommend using "toolbar" as "menubar" as name for "Desktop Menubar"s though, just to reduce conflict with the spec.
We have to be smart about how "Desktop Menubar"s would work though. Since toolbars generally appear almost as part of the actual application UI, applications will likely want to have a lot of control over how they are rendered. So we need to make them stylable using CSS. So we should define their rendering in terms of default rules in html.css or some such.
Comment 3•11 years ago
|
||
Ok, moving forward, I will be fleshing out a few more details around the draft here: https://wiki.mozilla.org/Apps/Menus. When it's at a good point will sync up with Myk and Marcos on next steps.
Comment 4•9 years ago
|
||
Per bug 1238079, we're going to disable the desktop web runtime and remove it
from the codebase, so we won't fix these bugs in the integration between Firefox and the runtime.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•