Closed Bug 881053 Opened 11 years ago Closed 7 years ago

Notifications API not working in content script DOM

Categories

(Add-on SDK Graveyard :: General, defect, P2)

Product:
Add-on SDK Graveyard
Component:
General
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: soufian.j, Assigned: gkrizsanits)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130605070403

Steps to reproduce:

Firefox 22 supports the new Notifications API that is available in the DOM scope. There's no documentation I could find on developer.mozilla.org. But here's an example snippet that works in the Web Console.
--
Notification.requestPermission(function(perm) {
        console.log(perm); if (perm !== 'granted') { return; }
new Notification("Test Notification",
              { body: "This is a notification."});
    });



In my SDK based addon, in the panel content script scope, I used this code.
function notifyExpired(title, msg) {
    if ((typeof Notification) !== 'undefined') {
        if (!($.data(window, 'hasAuthNotif'))) {
            let data = {title: title, msg: msg};
            Notification.requestPermission(function(perm) {
                if (perm !== 'granted') { return false; }
                $.data(window, 'hasAuthNotif', true);
                notifyExpired(data.title, data.msg);
            });
        } else {
            new Notification(title, {
               body: msg,
               dir: "auto",
               lang: "",
               tag: "",
               icon: getPath(document.baseURI) + "img/expired.png"
            });
        }
    } else {
        sendMessage('notify', {
            iconURL: getPath(document.baseURI) + "img/expired.png",
            title: title,
            text: msg
        });
    }
}



Actual results:

I got this error in the console:
Error: [Exception... "'PopupNotifications_show: invalid browser' when calling method: [nsIContentPermissionPrompt::prompt]"  nsresult: "0x8057001e (NS_ERROR_XPC_JS_THREW_STRING)"  location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]


Expected results:

I'm not sure if this is supported.
Summary: notification → Notifications API not working in content script DOM
If I'm understanding correctly, the panel is its own window/browser and in an add-on, you don't need to use the web API for it, but can just use the Notifications module in the SDK (https://addons.mozilla.org/en-US/developers/docs/sdk/latest/modules/sdk/notifications.html) -- can send a message back to the host from the panel script however, and call the Notifications module from the host without having to worry about permissions and the such
Gabor this feels like something related to the sandbox principals related bug. Do you think you could look into it ?
Flags: needinfo?(gkrizsanits)
Someone who has an idea about why PopupNotifications_show is called with a null browser in this setup in PopupNotifications.jsm can help you better I guess... I don't know anything about it. I would guess when our popup is associated with the hidden window frame, some logic somewhere cannot find any browser window. If there is a minimal reproducible example, I can try to debug it... Based on hg blame, Gavin might have an idea what's going on...
Flags: needinfo?(gkrizsanits) → needinfo?(gavin.sharp)
I don't know anything about what context this code is running in (not super familiar with addons SDK stuff), but the nsIContentPermissionPrompt::show implementation at http://hg.mozilla.org/mozilla-central/annotate/be23c06aab96/browser/components/nsBrowserGlue.js#l1646 would throw earlier (chromeWin.gBrowser would be null) if it were called for a content document that wasn't in a browser window, as far as I can tell. If getBrowserForDocument is returning null, something weirder is going on.
Flags: needinfo?(gavin.sharp)
I suppose the failure described in comment 0 is what would happen if the content document from which the request is coming from was in the browser window, but wasn't in one of the tabs (i.e. was in a separate frame not in that window's tabbrowser).
I believe in this case request will be coming of a Cu.Sandobox who's principal is window from one of the tabs.
Assignee: nobody → gkrizsanits
Priority: -- → P2
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #5)
> I suppose the failure described in comment 0 is what would happen if the
> content document from which the request is coming from was in the browser
> window, but wasn't in one of the tabs (i.e. was in a separate frame not in
> that window's tabbrowser).

I'm not sure I understand this request. You can anytime create a sandbox with the principal of any tab. You can even hook up the window in the proto chain of the sandbox.

(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #4)

> http://hg.mozilla.org/mozilla-central/annotate/be23c06aab96/browser/
> components/nsBrowserGlue.js#l1646 would throw earlier (chromeWin.gBrowser
> would be null) if it were called for a content document that wasn't in a
> browser window, as far as I can tell. If getBrowserForDocument is returning
> null, something weirder is going on.

Internally we use swapFrameLoaders that at some point swaps the viewer of an iframe of the hidden window and an iframe of the panel that I guess is in the browser window. Swapping at the 'right' moment can cause issues here I would suspect... I would first look into this part.

I can look into this if no one else volunteers, but it can take some time since I don't know much about this area.
(In reply to Gabor Krizsanits [:krizsa :gabor] from comment #7)
> Internally we use swapFrameLoaders that at some point swaps the viewer of an
> iframe of the hidden window and an iframe of the panel that I guess is in
> the browser window. Swapping at the 'right' moment can cause issues here I
> would suspect... I would first look into this part.

Who is "we"? Can you point me at the relevant code? That sounds like it would lead to exactly the scenario I describe in comment 5.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #8)
> 
> Who is "we"? Can you point me at the relevant code? That sounds like it
> would lead to exactly the scenario I describe in comment 5.

By we I was referring to jetpack / add-on sdk. https://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/panel/utils.js#250

I'm not very familiar with this code, I was planning to look into it tomorrow, but this is the point I was talking about.
https://bugzilla.mozilla.org/show_bug.cgi?id=1399562
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.