Requesting an API for menus, popups and panels for WebExtensions which would behave like their XUL predecessors. Currently, AFAIK, the only way to create a "popup" or "panel" with WebExtensions is to create a new chrome window with type=popup/panel. Actually, for the life of me, I do not see any difference in behavior when setting `type` to popup or panel. I am wondering what setting `type` even does. Here are some important points, and differences with simply opening a new chrome window: Speed: Opening a chrome window is *extremely* slow, compared to a XUL popup, which is nearly instantaneous. This point is a very big deal. Visibility: XUL popups/panels can appear partially or even completely outside of the parent window. This cannot be accomplished with HTML "popup" hacks which become invisible outside of the boundary of the window. Another very important point. Behavior: XUL popups are anchored to the current window, and disappear when clicking outside of the popup, or in the case of menupopups, clicking a menuitem when closemenu=none is not set. XUL panels can be anchored to the current window, or unanchored, yet always behave as a child of the window from which they were opened. XUL panels can optionally be closed by clicking outside of the panel. Scope: Code within both panels and menupopups run in the scope of the parent window. Another biggie. Hover hierarchical navigation: The XUL menu scheme of menupopups, when hovering over menu elements which opens more menupopups. I personally could manage without menu/menupopups, though that API is a mainstay of Firefox implementations. For my purposes, at least if panels could be created without creating a new window (slooooowwww), be visible outside of the parent window, and inherit the scope of the parent window, that would cover a lot of ground for my needs. Nevertheless, I would still recommend an API for the menu/menupopup navigation scheme.
+1 for the panel option. I currently modify the Webpage to show an overlay on top of the page, which is really ugly (and error-prone) compared to sdk/panel of my non-web-ext version.
Wondering if anything is happening with this?
This has been added to the agenda for the April 17 WebExtensions API triage meeting. Kevin, we would love to have you join us! Agenda: https://docs.google.com/document/d/1zKqhDqXoH9vi88q4DGtOHm1hsCF8ZwLNvCrrCE5htbc/edit# Call-in info: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Details_.26_How_to_Join
My mistake -- the meeting is April 18, not April 17. My apologies!
So, the meeting was 3 weeks ago, has the issue been discussed? Any news?
Sorry for the lack of updates from that meeting. Unfortunately the discussion wasn't too helpful and due to time constraints we had to move on to other APIs. We are a bit stuck on bugs like this. We can understand where the requests are coming from but struggle with the simple fact that this seems to go against the WebExtensions philosophy. Creating an API to show a panel and then all the APIs to control the panel is quite a lot of work and something we don't want to step into lightly.
Not sure why a new API is needed, the windows.create API already has everything in place, except for the disabled "panel" type: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/CreateType Not sure how the philosophy is different between a panel and a window.. the only difference between the two is whether or not window decorations are used (and maybe an automatic close when the panel loses focus) or am I missing something?
(In reply to Lusito from comment #7) > Not sure why a new API is needed, the windows.create API already has > everything in place, except for the disabled "panel" type: > https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/windows/ > CreateType > > Not sure how the philosophy is different between a panel and a window.. the > only difference between the two is whether or not window decorations are > used (and maybe an automatic close when the panel loses focus) or am I > missing something? There is a __LOT__ of difference between a panel and a window. See comment 0.
I believe what Kevin is getting at is that the panel (which is used BTW for browserAction and pageAction) is light weight compared to opening a new window (regardless of window decorations). Compare opening browserAction vs. opening a new window. Using a detached panel can be a handy alternative to a full window for simple UI stuff an addon may want to do. Personally I like the idea of having a detached panel, but there are a lot of considerations. Given the direction we're headed, the easy issue to point at with detached panels is lack of identifiable source by the user. A panel comes up, is it Firefox, the web page, or an addon? Our default is that any UI must tie back to its source in a way that is identifiable and controllable by the user. It also must not lend to easy abuse. So hidden in liking that idea is a lot of work to justify adding it. The other issue here is that it is a bug with an api (kind of) and problems (kind of), not a bug with clear use cases that can help us weigh against the plethora of other things being requested and those that we have to get done. That creates a much higher load on us to think things through. And if there is an alternative, even if not the most desirable, it will get lower time/consideration given everything that needs to get done.
Ah, I see.. about the identifiable source.. how about showing the addon-icon as part of the panel? with a tooltip (on the icon) showing the add-on title. I'd add that icon anyway for my user-story. I can see that this ticket is way too broad to be taken easily, but how about splitting it into different parts? I'd be willing to create 2 tickets with clear use-cases (any one of them would solve my needs). But if I write these 2 tickets, would they be closed because they look like duplicates of this one?
Here are the bugtickets: https://bugzilla.mozilla.org/show_bug.cgi?id=1364401 https://bugzilla.mozilla.org/show_bug.cgi?id=1364404
Whiteboard: [design-decision-needed] → [design-decision-needed] [needs-follow-up]
You need to log in before you can comment on or make changes to this bug.