Closed Bug 1096135 Opened 10 years ago Closed 6 years ago

"use strict"; violations only logged at LOG level from AddonManager.jsm callback


(Toolkit :: Add-ons Manager, defect)

33 Branch
Windows 7
Not set





(Reporter: peter.kehl, Unassigned, Mentored)



(Keywords: good-first-bug)


(1 file)

860 bytes, application/vnd.mozilla.xul+xml
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140923175406

Steps to reproduce:

Have an XUL with "use strict"; Javascript which calls AddonManager.getAllAddons(..). Pass a callback function that breaks strict Javascript. XUL attached

Actual results:

No log in Browser Console at ERROR or WARNING level. Only a log at LOG level:

1415588570479	addons.manager	WARN	Exception calling callback: ReferenceError: assignment to undeclared variable x (chrome://selite-extension-sequencer/content/extensions/test.xul:9:12) JS Stack trace: @test.xul:9:13 < safeCall@AddonManager.jsm:168:5 < getAddonsByTypes_noMoreObjects@AddonManager.jsm:2061:9 < AOC_callNext@AddonManager.jsm:263:7 < getAddonsByTypes_concatAddons@AddonManager.jsm:2056:11 < SocialAddonProvider.getAddonsByTypes@SocialService.jsm:1051:5 < callProvider@AddonManager.jsm:194:12 < getAddonsByTypes_nextObject@AddonManager.jsm:2053:1 < AOC_callNext@AddonManager.jsm:269:7 < getAddonsByTypes_concatAddons@AddonManager.jsm:2056:11 < PL_getAddonsByTypes@PluginProvider.jsm:148:5 < callProvider@AddonManager.jsm:194:12 < getAddonsByTypes_nextObject@AddonManager.jsm:2053:1 < AOC_callNext@AddonManager.jsm:269:7 < getAddonsByTypes_concatAddons@AddonManager.jsm:2056:11 < OpenH264Provider.getAddonsByTypes@OpenH264Provider.jsm:354:5 < callProvider@AddonManager.jsm:194:12 < getAddonsByTypes_nextObject@AddonManager.jsm:2053:1 < AOC_callNext@AddonManager.jsm:269:7 < getAddonsByTypes_concatAddons@AddonManager.jsm:2056:11 < LightweightThemeManager_getAddonsByTypes@LightweightThemeManager.jsm:390:5 < callProvider@AddonManager.jsm:194:12 < getAddonsByTypes_nextObject@AddonManager.jsm:2053:1 < AOC_callNext@AddonManager.jsm:269:7 < getAddonsByTypes_concatAddons@AddonManager.jsm:2056:11 < getAddonsByTypes_getVisibleAddons@XPIProvider.jsm:3689:7 < makeSafe/<@XPIProviderUtils.js:146:17 < asyncMap_gotValue@XPIProviderUtils.js:181:7 < asyncMap_callback@XPIProviderUtils.js:188:9 < completeAddon@XPIProviderUtils.js:135:5 < getAddon@AddonRepository.jsm:585:7 < this.AddonRepository.getCachedAddonByID<@AddonRepository.jsm:617:5 < TaskImpl_run@Task.jsm:314:40 < TaskImpl@Task.jsm:275:3 < createAsyncFunction/asyncFunction@Task.jsm:249:14 < getRepositoryAddon@XPIProviderUtils.js:137:3 < asyncMap_each@XPIProviderUtils.js:187:7 < asyncMap@XPIProviderUtils.js:185:3 < this.XPIDatabase.getAddonList/<@XPIProviderUtils.js:1071:9 < Handler.prototype.process@Promise-backend.js:866:23 < this.PromiseWalker.walkerLoop@Promise-backend.js:745:7

Expected results:

Since the callback stops executing (fatal violation of JS strict mode), it should generate ERROR and not WARNING.

This may not be specific to AddonManager. The issue may be related to
Attached file test.xul
Component: Untriaged → Add-ons Manager
Product: Firefox → Toolkit
See Also: → 1094057
Using the provided test.xul file I can see a different warning (see the screenshot ) in the browser console on Firefox 53.0a1 (2017-01-17) under Wind 7 64-bit.

What do you think about this Kris?
Flags: needinfo?(kmaglione+bmo)
We should probably just Cu.reportError those exceptions. I'm not sure if using the AOM logger has any utility there. But Log.jsm should also probably log warnings at the warning rather than message level.
Flags: needinfo?(rhelmer)
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(aswan)
It would be nice to distinguish where the exception is coming from.  Cu.reportError makes perfect sense if the exception is coming from front-end code.  If an exception is coming from an extension, it ought to be associated with that extension in the debugger, but I don't think that's all that practical so Cu.reportError everywhere is probably a reasonable thing to do.
Flags: needinfo?(aswan)
Ever confirmed: true
Flags: needinfo?(rhelmer)
AddonManager.getAllAddons(..) is not going to be possible in Firefox 57 when we move to WebExtensions, does that mean its still going to be relevant. Rob, if this a good first bug, we'd need a bit more detail about what the assignee of this bug should do.
(In reply to Andy McKay [:andym] from comment #5)
> AddonManager.getAllAddons(..) is not going to be possible in Firefox 57 when
> we move to WebExtensions, does that mean its still going to be relevant.
> Rob, if this a good first bug, we'd need a bit more detail about what the
> assignee of this bug should do.

AddonManager APIs will still be used by internal code (such as the WebExtensions implementation itself) and also things like privileged add-ons including webext experiments.

The goal here would be to use `Cu.reportError` for exceptions specifically, instead of simply logging them which is the norm right now. This includes but is not limited to `getAllAddons`.

Bonus points for figuring out how to associate exceptions coming from add-ons in the debugger somehow (comment 4) but just reporting the exceptions with reportError would be an improvement.
Mentor: rhelmer
Per policy at If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Closed: 6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.