The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in Firefox 12

Status

()

Core
XPCOM
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: Cyril, Assigned: bsmedberg)

Tracking

({addon-compat, regression})

12 Branch
mozilla12
x86_64
All
addon-compat, regression
Points:
---

Firefox Tracking Flags

(firefox12+ verified)

Details

(Whiteboard: [qa+])

Attachments

(3 attachments)

(Reporter)

Description

5 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
https://addons.mozilla.org/fr/firefox/addon/html-notifications/
and restart.
Go to http://code.google.com/p/ff-html5notifications/ 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 @paxal.net/html5notifications/notification-center;1

Addons Log after first restart :
*** LOG addons.xpi: startup
*** LOG addons.xpi: checkForChanges
*** LOG addons.xpi: Found updated metadata for html5notifications@paxal.net in app-profile
*** LOG addons.xpi: Processing install of html5notifications@paxal.net in app-profile
*** LOG addons.xpi: Opening database
*** LOG addons.xpi: New add-on html5notifications@paxal.net 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 @ http://code.google.com/p/ff-html5notifications/issues/detail?id=36

Comment 1

5 years ago
Regression window
Cannot reproduce:
http://hg.mozilla.org/mozilla-central/rev/4de07a341aab
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120111 Firefox/12.0a1 ID:20120111082226
Can reproduce:
http://hg.mozilla.org/mozilla-central/rev/17a76e33b6fe
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0a1) Gecko/20120111 Firefox/12.0a1 ID:20120111083049
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4de07a341aab&tochange=17a76e33b6fe

Suspected: Bug 675221
Blocks: 675221
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression

Updated

5 years ago
OS: Linux → All

Updated

5 years ago
Component: Untriaged → XPCOM
Product: Firefox → Core
QA Contact: untriaged → xpcom
(Assignee)

Comment 2

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

We hit the line "category JavaScript-global-property webkitNotifications @paxal.net/html5notifications/notification-center;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 http://hg.mozilla.org/mozilla-central/annotate/e0d9c8ddd5bd/dom/base/nsScriptNameSpaceManager.cpp#l724 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.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
(Assignee)

Comment 3

5 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.
(Reporter)

Comment 4

5 years ago
Hi,

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 @paxal.net/html5notifications/notification-center;1 {d931339b-60b1-4559-9459-a69ed1396561}
category JavaScript-global-property webkitNotifications @paxal.net/html5notifications/notification-center;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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Comment 5

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

Comment 6

5 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) :

https://addons.mozilla.org/fr/firefox/addon/js-print-setup/ (11.0b1 OK, 12.0a2 NOT OK)
Javascript property : jsPrintSetup
chrome.manifest : ordered

https://addons.mozilla.org/fr/firefox/addon/openid-for-firefox/ (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 :
http://paxal.net/bmo725016/

Comment 7

5 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:
http://mxr.mozilla.org/mozilla-central/source/xpcom/components/ManifestParser.cpp#511

Comment 8

5 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.

E.g.
chrome.manifest:
manifest components.manifest
category ...

components.manifest:
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:
https://mxr.mozilla.org/addons/source/1865/modules/Bootstrap.jsm#127
ABP hg is down ATM, at least for me, so here are the commits from a clone:
https://bitbucket.org/ericpaulbishop/trueblockplus/changeset/bc30fc47654a
https://bitbucket.org/ericpaulbishop/trueblockplus/changeset/5dfabe432ddb
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
(Assignee)

Comment 9

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

Updated

5 years ago
Assignee: nobody → benjamin
Status: REOPENED → ASSIGNED
(Assignee)

Comment 10

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

Comment 11

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

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

Comment 13

5 years ago
I have same problem, but can't solve by restart twice
(Assignee)

Comment 14

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/085725c8d753
https://hg.mozilla.org/integration/mozilla-inbound/rev/e550d86e3ee9

I totally screwed up the bug number in parts of this :-(
https://hg.mozilla.org/mozilla-central/rev/085725c8d753
https://hg.mozilla.org/mozilla-central/rev/e550d86e3ee9
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13

Comment 16

5 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
(Assignee)

Updated

5 years ago
status-firefox12: --- → affected
tracking-firefox12: --- → ?
(Assignee)

Comment 18

5 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?

Updated

5 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?
(Assignee)

Comment 21

5 years ago
https://hg.mozilla.org/releases/mozilla-aurora/rev/0d95e027554a
https://hg.mozilla.org/releases/mozilla-aurora/rev/8ed2f0e14adc
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.