chrome.notifications.create is ignored for the first time in WebExtensions

RESOLVED FIXED

Status

P2
normal
RESOLVED FIXED
3 years ago
4 months ago

People

(Reporter: 4mr.minj, Unassigned)

Tracking

Trunk
Bug Flags:
blocking-webextensions -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [notifications] triaged)

(Reporter)

Description

3 years ago
STR:
1) install https://github.com/mdn/webextensions-examples/tree/master/notify-link-clicks
2) go to https://www.example.org
3) middle click the 'more information...' link to open it in the background
Notice no notification was generated
4) repeat step 3) any number of times
Notice that a notification appears each time
5) Open Browser Console
Notice that 'background script received message' was logged each time (including the first)

As far as I can tell (via Browser Toolbox) the svc.showAlertNotification() function[1] is executed both times but it is silently ignored in the first instance for some reason.

[1] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/ext-notifications.js#31
(Reporter)

Updated

3 years ago
Whiteboard: [notifications]
(Reporter)

Comment 1

3 years ago
Since this maybe system related I was using a current nightly with e10s enabled on linux x64

Updated

3 years ago
Flags: blocking-webextensions+
Priority: -- → P2
Whiteboard: [notifications] → [notifications] triaged

Updated

3 years ago
Assignee: nobody → aswan

Updated

3 years ago
Iteration: --- → 47.3 - Mar 7

Updated

3 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Comment 2

3 years ago
I spent some quality time with gdb trying to trace this and the short of it is that nsAlertsIconListner creates an image load request for the alert icon, and then it listens for notifications here:
https://dxr.mozilla.org/mozilla-central/source/toolkit/system/gnome/nsAlertsIconListener.cpp#118

It needs to eventually see a FRAME_COMPLETE event in order to send the alert to libnotify, but the first time the alert is sent, we get three events: SIZE_AVAILABLE, HAS_TRANSPARENCY, LOAD_COMPLETED.  But no FRAME_COMPLETED event.  I spent a while tracing through code trying to figure out where that event should come from but ran out of time for the evening before figuring it out.
Note that the second time we send an alert, the image has now been loaded and decoded so we take a different code path and this time we get a different series of events: SIZE_AVAILABLE, FRAME_UPDATE, FRAME_COMPLETED.  The absence of the HAS_TRANSPARENCY event this time is mildly confusing but the alert icon listener doesn't care so lets let that slide for now...

I also can't find any recent documentation on the image loader so its hard to tell if this is a problem in the image loader itself or if nsAlertsIconListener is using the image loader incorrectly.

Kit, you were the last one to touch nsAlertsIconListener, do you have any insight?  Or can you suggest somebody well-acquainted with the image loader who I could talk to?
Flags: needinfo?(kcambridge)
That's a known issue in the libnotify backend. I started on a refactor in bug 1233086 a few months ago, which seemed to fix web notifications...but I didn't test extensions. The patch was just reviewed last week. Unfortunately, I don't have cycles to circle back to it until 48.

OOC, does it help if you change the `0 /* use default */` argument in https://dxr.mozilla.org/mozilla-central/rev/eb25b90a05c194bfd4f498ff3ffee7440f85f1cd/toolkit/system/gnome/nsAlertsIconListener.cpp#260 to `nsIContentPolicy::TYPE_INTERNAL_IMAGE`?

If that doesn't do it, :seth or :karlt would definitely be able to help. I don't know the image loading code at all. :-(
Flags: needinfo?(kcambridge)

Comment 4

3 years ago
Ah, 1233086 looks like the culprit, I'm just going to block this and I'll re-test when that gets resolved.
Thanks Kit!
Iteration: 47.3 - Mar 7 → ---
Depends on: 1233086

Updated

3 years ago
Duplicate of this bug: 1205730

Updated

3 years ago
Flags: blocking-webextensions+ → blocking-webextensions-

Updated

3 years ago
Assignee: aswan → nobody
Status: ASSIGNED → NEW

Comment 6

2 years ago
Martin offered to check if is fixed now that the fix for bug 1233086 has landed.
Flags: needinfo?(martin)
I can no longer reproduce this on elementary OS 0.2 with a libnotify (that gets accepted as notification lib by Firefox) and a build based off m-c from about 10 hours ago as of this comment.
Flags: needinfo?(martin)

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Updated

4 months ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.