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

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Peter Kehl]

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 < [e-mail]:168:5 < [e-mail]:2061:9 < [e-mail]:263:7 < [e-mail]:2056:11 < [e-mail]:1051:5 < [e-mail]:194:12 < [e-mail]:2053:1 < [e-mail]:269:7 < [e-mail]:2056:11 < [e-mail]:148:5 < [e-mail]:194:12 < [e-mail]:2053:1 < [e-mail]:269:7 < [e-mail]:2056:11 < [e-mail]:354:5 < [e-mail]:194:12 < [e-mail]:2053:1 < [e-mail]:269:7 < [e-mail]:2056:11 < [e-mail]:390:5 < [e-mail]:194:12 < [e-mail]:2053:1 < [e-mail]:269:7 < [e-mail]:2056:11 < [e-mail]:3689:7 < makeSafe/<@XPIProviderUtils.js:146:17 < [e-mail]:181:7 < [e-mail]:188:9 < [e-mail]:135:5 < [e-mail]:585:7 < this.AddonRepository.getCachedAddonByID<@AddonRepository.jsm:617:5 < [e-mail]:314:40 < [e-mail]:275:3 < createAsyncFunction/[e-mail]:249:14 < [e-mail]:137:3 < [e-mail]:187:7 < [e-mail]:185:3 < this.XPIDatabase.getAddonList/<@XPIProviderUtils.js:1071:9 < [e-mail]:866:23 < [e-mail]: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 https://bugzilla.mozilla.org/show_bug.cgi?id=1094057.

Comment 1

[Peter Kehl]

Attachment: test.xul

Comment 2

[CosminB]

Using the provided test.xul file I can see a different warning (see the screenshot https://www.screencast.com/t/ts3UpBoyI ) in the browser console on Firefox 53.0a1 (2017-01-17) under Wind 7 64-bit.

What do you think about this Kris?

Comment 3

[Kris Maglione [:kmag]]

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.

Comment 4

[Andrew Swan [: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.

Comment 5

[Andy McKay]

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.

Comment 6

[Robert Helmer [:rhelmer]]

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

Comment 7

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.