Both of these are available to overlay extensions. I couldn't find any bug about their fate in the WebExtensions world. https://dxr.mozilla.org/addons/search?q=getNotificationBox https://dxr.mozilla.org/addons/search?q=PopupNotifications.show

I definitely wouldn't want to lose PopupNotifications.show. It's a very elegant way to cue the user that a prompt is scoped to the current origin.

I swear we had a bug for this already in the past, but I can't find it. I think we should do this. The ability to get the notification box and change it should probably limited to the extension. I.E. the extension can create and edit its own notification boxes, but not others.

Note that neither the notification anchor icons nor the popup notification content are currently very extendable if you're not pushing to mozilla-central. I believe this is a good thing, since these popups should be very consistent in style and design. Simple text-based messages with an optional input and a checkbox could work, though. We should anchor popup notifications at the browser action or page action icons, that's IMO the best solution since it makes clear which extension spawned the prompt, avoids the overhead of policing icon styling, prevents maliciously changing the identity block and is IMO easiest to implement. Also note that popup spamming is a real problem that we will have to constantly battle after implementing this. IIRC Chrome disabled spawning browserAction popups because of this and a lot of site are abusing lax browser practices on permission requests to spam the user until they consent. We need a plan for giving the users anti-spamming options e.g. giving the user an easy option to not see messages from a certain extension. In fact, I would be happy if this could be its own manifest permission. With the caveats considered I'm still a big fan of this since I can see a lot of potential use cases.

Based on Johann's comment is this just a dupe of exposing the browserAction.show() with this implementation? Given that we will likely never want the doorhanger open at the same time we are just enforcing a consistent template to the door hanger from the extension. I agree with Johann's comment about requiring another permission for this.

Not sure why a permission system would be needed for this.. If the extension shows popups to the user which the user does not want, he can just uninstall the extension. It should be up to the extension developer to add options to control how often the popups appear. Aside from that, if someone really wanted to do harm with these kind of popup messages in their extension, shouldn't the reviewers check for this kind of code?

Hi all, this has been added to the agenda for the May 9 WebExtensions API triage. Hector and Stephan, would you be able to join us? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage Agenda: https://docs.google.com/document/d/1q7UD3DxsT5z0lO3EbOyF9Iln32Wg_e9LYMdHZ80BEb4/edit#

I wouldn't create a new namespace for this. I think the way to go is simply to extend the chrome.notifications API to support a new "infobar" type.

(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #6) > Hi all, this has been added to the agenda for the May 9 WebExtensions API > triage. Hector and Stephan, would you be able to join us? Thanks for letting me know, but this would be 01:30-02:00 AM for me, guess I'll skip.

I only just realized that there wasn't another, more important "Stephan" who'd commented on the bug when Hector's quote of the original message brought it to my attention a second time. I've dropped into IRC, but, if I'm remembering my timezones correctly, it's already 8 minutes into the allocated time.

Never mind. I just realized my mistake. 10:30-11:00 AM, not PM. I won't be able to attend. While I *am* in EST (UTC-5 winter, UTC-4 summer), I'm nocturnal. (Trying to fix that and failing repeatedly is what led to the sleep deprivation that confused me in the first place.)

Thank you, Hector and Stephan! We will update the bug once a design decision has been reached.

First, the notification bar has a high probability of going away, nothing is really using it any longer (other than addons perhaps and maybe popup blocker). The correct UI in Firefox at this point would be a door hanger. That doesn't preclude different ui (see request below). I don't think anchoring a notification to a UI element used for something else is a good idea. If it were attached to a browser action, it is awkward to have the user click on the browser action again to get a different panel (or require ui hurdles in the addon, or some other strange effect due to the onclick listener). What we would really like to get are 2 or 3 really solid user stories. That would give us a point from which to really think about the alternatives.

I'm not pro any certain flow, however I can tell you containers assignment flow would be cleaner with permission prompt, site identity door hangers. Flow 1: 1. User clicks context menu "Always open in this container" 2. We throw a Notification to inform the user this action has been completed Alerts, in content notices or page redirection are not much better here Flow 2: 1. User clicks a link they have assigned 2. User is redirected to a full page approval screen - Notifications don't help as they don't allow prompting the user - Confirm dialogs are ugly - In content prompts don't help redirection and are potentially subject to page spoofing/modification

(In reply to Shane Caraveo (:mixedpuppy) from comment #12) > I don't think anchoring a notification to a UI element used for something > else is a good idea. If it were attached to a browser action, it is awkward > to have the user click on the browser action again to get a different panel > (or require ui hurdles in the addon, or some other strange effect due to the > onclick listener). Actually, I was envisioning a WebExtensions API that would allow extensions to present a dedicated icon plus popup on the left end of the address bar, similar to how the password manager and geolocation permission prompt function. Essentially, what I'd like to see is a "page action of the notification world" to complement the existing "browser action of the notification world" mechanism, with the former being tied more strongly to the navigation flow, both in how users perceive it and in having its lifecycle under the browser's control, rather forcing an "all or none" approach to integrating with OS notifications. As mentioned, it'd also provide a good attachment point for designing un-spoofable credential prompts for ideas like the unified account manager and login/logout UI for HTTP Basic Auth, OpenID, etc. which Persona's precursor proposed.

(In reply to Shane Caraveo (:mixedpuppy) from comment #12) Sorry for the delay in response. > First, the notification bar has a high probability of going away, nothing is > really using it any longer (other than addons perhaps and maybe popup > blocker). The correct UI in Firefox at this point would be a door hanger. > That doesn't preclude different ui (see request below). It feels like to me that the door hanger is more likely to be dismissed and ignored than the notification bar. > > What we would really like to get are 2 or 3 really solid user stories. That > would give us a point from which to really think about the alternatives. Two scenarios in which we're still using the notification bar (which may not be possible in the WebExtensions world due to lack of other APIs): 1. check the homepage pref for known hijacks after each Fx upgrade, and call for the affected user to reset the homepage pref; 2. detect the unusual slow loading of Google searchs (quite common in China), and suggests searching with Baidu instead, maybe also switch the default search engine. Generally speaking, it's about letting an user know about what's wrong with the current page, and what they can do to resolve it.

(In reply to Shane Caraveo (:mixedpuppy) from comment #12) > First, the notification bar has a high probability of going away, nothing is > really using it any longer (other than addons perhaps and maybe popup > blocker). Also this is still used in a couple of places, not limited to the popup blocker: https://dxr.mozilla.org/mozilla-central/search?q=getNotificationBox+-path%3Adevtools+-path%3Atest&redirect=false

Would love to see this persist even as a privileged WebExt API. Test Pilot uses it and Shield does as well AFAIK.

notificaton available isn't in right place in user interaction flow now for the mozilla china add-ons

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1364404

Bumping this back to P2 to support the need to migrate internal Mozilla system components to WebExtensions.

I personally think we should implement the following for "getNotificationBox" browser.notifications.create("my-prompt", { type: "prompt", message: "Something went wrong please approve", buttons: [ {title: "Ok"}, {title: "Cancel"}, ], priority: 1, location: "bottom" // We have top and bottom locations currently. }); browser.notifications.onButtonClicked.addListener((id, index) => { // id = "my-prompt", index = 1 }); Issues for this: 1. We would have to reimplement the schema for all other "type" notifications into toolkit/components/extensions/parent/ext-notifications.js rejecting: a. When title wasn't supplied throw b. When buttons was supplied throw until the other types supported this. 2. We would have to implement onButtonClicked which wouldn't fire for other types. This design follows the current API design adding in the "prompt" type and "location" type. This also permits us changing what this actually looks like in the future.

Patch attached of me playing about.

Hey Mike, Is the super WIP patch something your team would be able to triage for the API? I'm working on using this for an experiment and it would be nice if we can turn it into something other developers can use (perhaps it's even fine to give to non privileged addons). Thanks

Thanks for reaching out, jkt. I see this bug went through a design-decision triage about a year ago, but the outcome of that meeting isn't clear (and occurred prior to me joining the team). However, based on indirect evidence it seems like it was approved (since Andy, at one point, had me bump this to P2). mixedpuppy: Any fresh thoughts on this, given a year's worth of hindsight? I like jkt's approach of reusing an existing namespace and API. Can the underlying code be counted on for continued support (comment 12 has me worried still)? Are there still internal add-ons who need/want this (comment 17)? Would we make it Mozilla privileged?

I dont think the API itself is an issue. It's the UI. I think UX should agree to whatever we choose to use as a longer term solution. Aside from UX/UI approval/design, I'd prefer to to define a location as that ties down part of the implementation. Maybe we want it at the bottom now. Maybe in 5 years we want it at the top. who knows. A scope would be useful, such as [tab, window, application].

"I'd prefer to NOT define a location"

I agree with the renaming location to scope. The same rationale of being UX independent was used instead of naming it infobars like Chrome does too. Scope would work too and then hopefully be flexible enough for the next iteration of this UI. I'm not sure who we ask from UX if this fits with any plans they may have.

Emanuela, we have extension authors (internal and external) who are interested in making use of the notification box. Can you provide some UX perspective on this? Do you see that UI feature being continued in the product?

The notification box is used pretty extensively, I wouldn't worry too much about it suddenly disappearing. I think the bigger problem is that we use that for notifications that come from the browser itself, and the danger here is that malicious extensions could trick users into thinking a notification is coming from the browser unless we do something to clearly distinguish it as originating from an extension.

We could use the solution used elsewhere and make the icon default to the extension itself (Mozilla signed addons could then change this).

(In reply to Andrew Swan [:aswan] from comment #29) > The notification box is used pretty extensively, I wouldn't worry too much > about it suddenly disappearing. I think the bigger problem is that we use > that for notifications that come from the browser itself, and the danger > here is that malicious extensions could trick users into thinking a > notification is coming from the browser unless we do something to clearly > distinguish it as originating from an extension. I don't think this is a big issue. Since notification boxes overlay web content anyone could easily craft a content script and CSS that spawns a perfect looking fake notification box in content land (and malicious/spam websites already do this to mislead users). As Jonathan said, it would also be easy to add indicators that this comes from an extension, such as forcing the use of the extension icon or adding a small "Notification by [Addon Name]" notice.

(In reply to Johann Hofmann [:johannh] from comment #31) > I don't think this is a big issue. Since notification boxes overlay web > content anyone could easily craft a content script and CSS that spawns a > perfect looking fake notification box in content land (and malicious/spam > websites already do this to mislead users). Okay, but its not totally trivial. First, the extension needs permission to inject a content script. Second, notification box uses a xul (native) button, which looks different from an in-content html button. These can both be overcome of course. > As Jonathan said, it would also be easy to add indicators that this comes > from an extension, such as forcing the use of the extension icon or adding a > small "Notification by [Addon Name]" notice. Yes, I think this should be done if we are going to pursue this.

(In reply to Andrew Swan [:aswan] from comment #32) > (In reply to Johann Hofmann [:johannh] from comment #31) > > As Jonathan said, it would also be easy to add indicators that this comes > > from an extension, such as forcing the use of the extension icon or adding a > > small "Notification by [Addon Name]" notice. > > Yes, I think this should be done if we are going to pursue this. I also agree with this, but I think it should be clearly decided that the primary purpose is not security (since an extension *could* just go the content script route if it really wants to) but, rather, to make it as easy as possible for users to identify the extension responsible for a UI behaviour they want to change or remove.

(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #28) > Emanuela, we have extension authors (internal and external) who are > interested in making use of the notification box. Can you provide some UX > perspective on this? Do you see that UI feature being continued in the > product? As a general rule, when we have a message coming from an extension, we should display: - the extension icon (if no extension icon is available, fallback on the puzzle piece) - extension's name (if possible, with a stronger font-weight) As :mixedpuppy suggested, I'd like to have this guideline 'location'/'surface' agnostic. :) We can implement those like they are and make some small adjustments, if needed, later.