Need to restart firefox 12.0a2 twice to get specific extension to work

RESOLVED FIXED in Firefox 12



6 years ago
5 years ago


(Reporter: Cyril, Assigned: Benjamin Smedberg)


({addon-compat, regression})

12 Branch
addon-compat, regression

Firefox Tracking Flags

(firefox12+ verified)


(Whiteboard: [qa+])


(3 attachments)



6 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120205184700

Steps to reproduce:

Install Firefox 12.0a2 and create fresh profile.
Install extension at
and restart.
Go to and test notifications.

Actual results:

Firefox says functionnality is not available.

Expected results:

Firefox should have asked for notification permission.

After a second restart, Firefox does ask for notification permission.

This extension uses no binary code, but (among others) Javascript XPCOM and javascript global property with chrome.manifest registration
category JavaScript-global-property webkitNotifications;1

Addons Log after first restart :
*** LOG addons.xpi: startup
*** LOG addons.xpi: checkForChanges
*** LOG addons.xpi: Found updated metadata for in app-profile
*** LOG addons.xpi: Processing install of in app-profile
*** LOG addons.xpi: Opening database
*** LOG addons.xpi: New add-on installed in app-profile
*** LOG addons.xpi: Updating database with changes to installed add-ons
*** LOG addons.xpi: Updating add-on states
*** LOG addons.xpi: Writing add-ons list

See issue @

Comment 1

6 years ago
Regression window
Cannot reproduce:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120111 Firefox/12.0a1 ID:20120111082226
Can reproduce:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120111 Firefox/12.0a1 ID:20120111083049

Suspected: Bug 675221
Blocks: 675221
Ever confirmed: true
Keywords: regression


6 years ago
OS: Linux → All


6 years ago
Component: Untriaged → XPCOM
Product: Firefox → Core
QA Contact: untriaged → xpcom

Comment 2

6 years ago
This extension needs to be fixed. What's happening is:

We hit the line "category JavaScript-global-property webkitNotifications;1" in chrome.manifest. When we process this line, before the patch we would post an event to the event loop to notify observers. The new behavior is that we immediately notify observers. Both behaviors are correct, but the new behavior is much more efficient.

This ends up immediately at which fails because the contractID isn't registered yet.

This would be solved by reordering chrome.manifest so that you register the contractid/CID *before* you add the category.

It's not clear to me why this works correctly on non-first runs, but that actually sounds like a bug that we need to fix; the behavior should be consistent.
Last Resolved: 6 years ago
Resolution: --- → INVALID

Comment 3

6 years ago
The reason this doesn't happen on second-startup is that we initialize the nsScriptNameSpaceManager later in startup, so that it doesn't have to cache the results.

Comment 4

6 years ago

Thank you for such quick replies.

I reordered chrome.manifest lines, but the problem is still here.
The components are accessible, but the JavaScript global-property is not.

Extract of chrome.manifest :
# notification center object
interfaces components/nsIPXLNotificationCenter.xpt
component {d931339b-60b1-4559-9459-a69ed1396561} components/nsIPXLNotificationCenter.js
contract;1 {d931339b-60b1-4559-9459-a69ed1396561}
category JavaScript-global-property webkitNotifications;1

I will ask other AMO Editors if they can find other addons that could be concerned with this issue. Maybe it's a problem with mine only.
Resolution: INVALID → ---

Comment 5

6 years ago
Created attachment 595321 [details]
Extension with reordered chrome.manifest file : category command at the end

Comment 6

6 years ago
I tested 3 (mine + 2) of the 12 addons with JavaScript-global-property in chrome.manifest (thank you AMO editors for the list) : (11.0b1 OK, 12.0a2 NOT OK)
Javascript property : jsPrintSetup
chrome.manifest : ordered (11.0b1 OK, 12.0a2 NOT OK)
Javascript property : openid
chrome.manifest : ordered

All addons with Global JS Property stop working after 1st restart, and work again after second restart (even the addons that were already installed).

Small interface to test if a window.javascriptProperty exists :

Comment 7

6 years ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> This would be solved by reordering chrome.manifest so that you register the
> contractid/CID *before* you add the category.

Reordering will not have any effect as contracts are special cased in the manifest parser to be registered last:

Comment 8

6 years ago
A viable work-around would be to register components in a separate manifest and link that from the main manifest, as the Parser will only delay contract registration on a per manifest basis.

manifest components.manifest
category ...

interfaces ...
component ...
contract ...

Right now nsScriptNameSpaceManager.cpp - the global javascript components - and the nsIStringBundleService (checking for nsIStringBundleOverride.idl) are the only code bits in core code that observe "xpcom-category-entry-added".

The only addons mxr listed add-on observing the notification is AdBlock Plus, using this as a way for other extensions to load modules conditionally on ABP being installed:
ABP hg is down ATM, at least for me, so here are the commits from a clone:
There are no addons mxr listed add-ons registering themselves to the "adblock-plus-module-location" category.

If this bug does not get fixed, this definitively needs a note regarding js globals, stringbundle overrides and the xpcom-category-entry-added notification in the compatibility report Jorge publishes on the addons blog.
Keywords: addon-compat

Comment 9

6 years ago
Hrmph. I guess we should always asynchronously dispatch this notification. Patch forthcoming :-(


6 years ago
Assignee: nobody → benjamin

Comment 10

6 years ago
Created attachment 595456 [details] [diff] [review]
Patch, make category delivery always be asynchronous, rev. 1
Attachment #595456 - Flags: review?(bzbarsky)

Comment 11

6 years ago
Created attachment 595457 [details] [diff] [review]
Comment on attachment 595456 [details] [diff] [review]
Patch, make category delivery always be asynchronous, rev. 1

Attachment #595456 - Flags: review?(bzbarsky) → review+

Comment 13

6 years ago
I have same problem, but can't solve by restart twice

Comment 14

6 years ago

I totally screwed up the bug number in parts of this :-(
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13

Comment 16

6 years ago
Target Milestone set to mozilla13, is that mean only in firefox 13?
so, firefox 12a2 won't enjoy the fix, right?
Duplicate of this bug: 696117


6 years ago
status-firefox12: --- → affected
tracking-firefox12: --- → ?

Comment 18

6 years ago
Comment on attachment 595456 [details] [diff] [review]
Patch, make category delivery always be asynchronous, rev. 1

This is pretty low-risk, it reverts this specific case to the previous behavior and comes with a test.
Attachment #595456 - Flags: approval-mozilla-aurora?


6 years ago
tracking-firefox12: ? → +
Comment on attachment 595456 [details] [diff] [review]
Patch, make category delivery always be asynchronous, rev. 1

[Triage Comment]
This low-risk patch fixes a reproducible bug when an add-on needs notification permissions. Approved for Aurora 12.
Attachment #595456 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
This hasn't yet landed on Aurora 12 - can we do that soon so that this doesn't land right before the cutover to beta?

Comment 21

6 years ago
status-firefox12: affected → fixed
Target Milestone: mozilla13 → mozilla12
Whiteboard: [qa+]
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20100101 Firefox/12.0

Verified with steps from comment 0 on Ubuntu 11.10 x86_64 and Mac OS 10.6. Notifications appear after restarting.
status-firefox12: fixed → verified
You need to log in before you can comment on or make changes to this bug.