Closed Bug 1488247 Opened 6 years ago Closed 6 years ago

chrome.notifications.onClicked Handler Not Called Sometimes

Categories

(WebExtensions :: Untriaged, defect)

defect
Not set
normal

Tracking

(firefox62 affected, firefox63 affected, firefox64 affected)

RESOLVED INVALID
Tracking Status
firefox62 --- affected
firefox63 --- affected
firefox64 --- affected

People

(Reporter: ilyaigpetrov, Unassigned)

Details

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

Create a web extension with popup triggering notification and see that notification listener is not always called.
Specifically listener is not called if you click notification quickly.

OS: Linux, Lubuntu 18.04.1

# Steps

1. Temporary install attached extension from about:debugging.
2. Click the first notification when extension is launched.
3. Open developer tools by clicking "Debug".
4. See notification click handler caught your click.
5. Open popup window and click the popped notification quickly.
6. In DevTools see that click wasn't caught.
7. Open popup, quickly click button "NOTIFY", quickly click corresponding notification.
8. In DevTools see that click wasn't caught.
9. Try waiting before clicking notifications and see that postponed clicks are handled sometimes.

# mainfest.json

```json
{

  "manifest_version": 2,

  "name": "Notifications Test",
  "description": "Blow up internet!",
  "version": "0.0.0.1",
  "author": "homerjsimpson@example.com",
  "homepage_url": "https://cool-extension.example.com",

  "permissions": [
      "activeTab"
    , "notifications"
    , "<all_urls>"
  ],

  "background": {

    "scripts": [
      "./index.js"
    ]

  },

  "browser_action": {
    "default_popup": "./pages/popup/index.html"
  }

}
```

# index.js (background script)

```js
'use strict';

console.log('Extension started.');

window.notify = (id) => {

  const opts = {
    title: id,
    message: 'MESSAGE',
    contextMessage: 'NOTY TEST',
    type: 'basic',
    isClickable: true,
  };
  chrome.notifications.create(id, opts);
};

chrome.notifications.onClicked.addListener(
  (id) => {

    console.log(`NOTIFICATION "${id}" WAS CLICKED!`);
    console.log('=================================');
  },
);

window.notify('From BG index.js'); // Click is handled.
```

# index.js of the popup page

```js
'use strict';

chrome.runtime.getBackgroundPage(
  (bgWindow) => {

    document.getElementById('btn').onclick =
      () => bgWindow.notify('From PUP button');  // Click is not always handled.

    bgWindow.notify('From PUP index.js'); // Click is not always handled.
  },
);
```


Actual results:

Clicks on notifications are not handled sometimes.


Expected results:

All clicks must be handled by a notification listener.
I managed to reproduce this issue on Ubuntu 16.04, Nightly 64.0a1 (2018-09-05), FF 62.0 and FF 63.0b3.
Status: UNCONFIRMED → NEW
Component: Untriaged → Event Handling
Ever confirmed: true
Product: Firefox → Core
Version: 63 Branch → Trunk
Can you make this happen outside of an extension?
Flags: needinfo?(ilyaigpetrov)
(In reply to Andrew Overholt [:overholt] from comment #2)
> Can you make this happen outside of an extension?

No, it happens only in the extension popup window.

I've tried:

1. index.html opens popup.html which creates a notification. Clicking the notification quickly always triggers the listener inside popup.html.
2. index.html opens popup.html which creates a notification, but popup is then closed by index.html before user clicks the notification. Result: notification is destroyed as soon as popup.html is closed. In the extension attached notification is created by background page and thus closing the popup doesn't destroy notification (notification click listener is also installed in the background page).
3. index.html opens popup.html which uses window.opener.postMessage to post notification title (as string or as object) to index.html which upon receiving the message closes popup.html and creates notification with the title received. Result: notification with the title is created by index.html, clicking this notification triggers the listener.
Flags: needinfo?(ilyaigpetrov)
Thanks for doing all that testing!
Component: Event Handling → Untriaged
Product: Core → WebExtensions
Flags: needinfo?(lgreco)
We tried to reproduce on Linux (Ubuntu 18.04 + KDE, Ubuntu 17.04 + GNOME) and cannot reproduce the issue - the onClicked listener is always triggered.

To rule out any system-specific integration issues, could you visit about:config and set alerts.useSystemBackend to false? This will force Firefox to use its own desktop notifications UI.

Depending on where you click, either browser.notifications.onClicked or browser.notifications.onClosed is fired.
Can you modify your test case and add a listener for browser.notifications.onClosed to check whether onClosed is called when onClicked is not?
Flags: needinfo?(lgreco) → needinfo?(ilyaigpetrov)
1. Setting alerts.useSystemBackend to false fixes the misbehavior.
2. chrome.notifications.onClosed is always triggered even when chrome.notifications.onClicked isn't.
3. If chrome.notifications.onClicked is triggered then chrome.notifications.onClosed always follows afterwards.
Flags: needinfo?(ilyaigpetrov)
Added a listener for chrome.notifications.onClosed.
Attachment #9006048 - Attachment is obsolete: true
If I close the extension popup window and activate notification afterwards then it is always triggered.
I think it's a focus bug: notification gains focus only after popup window is closed (and looses focus).
As already noted the system is Lubuntu 18.04.1 (LXDE):

$ apt show lxde
Package: lxde
Version: 10
With alerts.useSystemBackend set to false notification must be clicked twice: 1st click closes the popup window, second click activates the notification. This behavior may be not wanted.

In Chrome one click on the notification is enough. There is no need to close the popup window.
Notification is focusable without closing the popup.
Add Chrome support (by adding required notification icon).
Attachment #9013978 - Attachment is obsolete: true
Neither your test case, nor the implementation of the extension notifications API shows any obvious relation between the extension popup panel (as a trigger for the notification) and the desktop notification. I wonder whether this bug also occurs if you show a notification while another kind of popup is being shown while the notification is created, such as a context menu.

(In reply to ilyaigpetrov from comment #8)
> If I close the extension popup window and activate notification afterwards
> then it is always triggered.
> I think it's a focus bug: notification gains focus only after popup window
> is closed (and looses focus).

If popup autohiding is disabled, does the bug still occur (with system desktop notifications)?
You can disable popup autohide via the Debug button at about:debugging, and then the "Disable popup auto-hide" option in the triple-dot menu at the upper-right corner in the Developer tools.

And can you reproduce the problem if you use the DOM Notification API (https://developer.mozilla.org/en-US/docs/Web/API/notification )?

Notification.requestPermission().then((result) => {
  console.assert(result === "granted", `${result} should be granted`);
  let n = new Notification('title');
  n.onclick = n.onclose = e => console.log(e.type);
});

// Expected: click, close
(If you see "close" before having closed the notification, see bug 1418281 ).
Attached file ext-notifications-focus.webm (obsolete) (deleted) —
> If popup autohiding is disabled, does the bug still occur (with system desktop notifications)?

The first notification doesn't gain focus (hovering "Activate" button doesn't highlight it) and so click is not handled.
After the first notification is clicked and closed all subsequent notifications gain focus and click handler is invoked.

> And can you reproduce the problem if you use the DOM Notification API (https://developer.mozilla.org/en-US/docs/Web/API/notification )?

The misbehavior is the same. If popup autohiding is disabled the misbehavior is also the same.
Flags: needinfo?(rob)
I installed Lubuntu 18.04.1 and managed to reproduce the bug, even without extensions.
However, this is not a bug in Firefox, but in the notification system of LXDE (or whatever Lubuntu is using).

STR.
1. Boot Lubuntu 18.04.1 (live ISO works too).
2. Open the terminal, start dbus-monitor:

   dbus-monitor interface=org.freedesktop.Notifications

3. Start Firefox, and trigger a notification, either via the code snippet in comment 11,
   or by clicking on the button at https://mdn.mozillademos.org/en-US/docs/Web/API/notification$samples/Example?revision=1408180

4. Open the context menu anywhere (e.g. in Firefox, or in the terminal).
5. Try to click on the "Activate" button of the notification.
6. Look at the output of the terminal (dbus-monitor output) - expect ActionInvoked followed by ActionClosed.

Expected (this happens on LXDE when step 4 is skipped):
- After step 6, expect three messages:
   member=Notify (from step 3)
   member=ActionInvoked (this is the click event)
   member=NotificationClosed (this is the close event)
   (Note: on KDE, this last notification seems to only happen when a new notification is opened)

Actual (on LXDE):
- After step 6, the following are observed:
   member=Notify
   member=NotificationClosed
   (member=ActionInvoked is missing)

Since the notification backend does not send an ActionInvoked message, Firefox cannot know that the user has clicked on the notification, and the absence of the "click" event is expected.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(rob)
Resolution: --- → INVALID
Group: toolkit-core-security
This is not a security bug. Why did you mark it as such?
Flags: needinfo?(ilyaigpetrov)
The content of attachment 9014010 [details] has been deleted for the following reason:

Deleted at the request of the user via ddurst
Reversing toolkit-core-security flag, which does not apply.
Group: toolkit-core-security
Flags: needinfo?(ilyaigpetrov)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: