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

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, defect, P2)

Description

[Mindaugas <LA-MJ>]

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

Comment 1

[Mindaugas <LA-MJ>]

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

Comment 2

[Andrew Swan [:aswan]]

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?

Comment 3

[Lina Butler [:lina]]

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. :-(

Comment 4

[Andrew Swan [:aswan]]

Ah, 1233086 looks like the culprit, I'm just going to block this and I'll re-test when that gets resolved.
Thanks Kit!

Comment 6

[Andrew Swan [:aswan]]

Martin offered to check if is fixed now that the fix for bug 1233086 has landed.

Comment 7

[Martin Giger [:freaktechnik]]

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.