1287824 - NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Jakub Czerny]

Attachment: page.html

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160606100503

Steps to reproduce:

Loaded an  intranet page that returned attached response.

Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
from Fedora packages


Actual results:

Only one network request, with 200 response, 

In console: NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS: [JavaScript Error: "shouldLog is not a function" {file: "resource://gre/modules/Console.jsm" line: 464}]'[JavaScript Error: "shouldLog is not a function" {file: "resource://gre/modules/Console.jsm" line: 464}]' when calling method: [nsIFormSubmitObserver::notify]
 login.jspa:172:0

The page area is completely blank


Expected results:

Page loaded

Comment 1

[Tooru Fujisawa [:arai]]

Looks like a similar issue to bug 1287598.

Comment 2

[Tooru Fujisawa [:arai]]

Does the issue also happen by opening attachment 8772426 [details] ?

Comment 3

[:Gijs (he/him)]

Can you post a copy of the contents of about:support (Help > Troubleshooting Information) ?

Comment 4

[Peter Bengtsson [:peterbe]]

That kind of TypeError can only happens if shouldLog is not undefined and not a callable. The only places I, with my limited knowledge, can find are: https://dxr.mozilla.org/mozilla-central/source/devtools/client/responsive.html/store.js and https://dxr.mozilla.org/mozilla-central/source/browser/components/feeds/FeedWriter.js which, in both cases, carefully define shouldLog with a local scope. Is there any chance that could have gone rogue/corrupt?

Comment 5

[Tooru Fujisawa [:arai]]

what I can think of is, resource://gre/modules/Console.jsm somehow gets unloaded.
Executing the following script in scratch pad with browser environment can throw similar error.

  var tmp = Cu.import("resource://gre/modules/Console.jsm", {});
  var c = tmp.console;
  Cu.unload("resource://gre/modules/Console.jsm");
  c.log("hello");

Comment 6

[:Gijs (he/him)]

(In reply to Peter Bengtsson [:peterbe] from comment #4)
> That kind of TypeError can only happens if shouldLog is not undefined and
> not a callable. The only places I, with my limited knowledge, can find are:
> https://dxr.mozilla.org/mozilla-central/source/devtools/client/responsive.
> html/store.js and
> https://dxr.mozilla.org/mozilla-central/source/browser/components/feeds/
> FeedWriter.js which, in both cases, carefully define shouldLog with a local
> scope. Is there any chance that could have gone rogue/corrupt?

(In reply to :Gijs Kruitbosch from comment #3)
> Can you post a copy of the contents of about:support (Help > Troubleshooting
> Information) ?

Comment 7

[Peter Bengtsson [:peterbe]]

Attachment: peterbe.about.support

Comment 8

[:Gijs (he/him)]

At least Test Pilot's Universal Search add-on does this ( https://github.com/mozilla/universal-search/issues/267 ) and so does SlyZoom ( https://addons.mozilla.org/en-US/firefox/addon/slyzoom/ - not looked if I can find an issue ).

Pinging Jorge - can we write a guideline that it's basically always wrong to call Cu.unload on anything except the add-on's own modules and make sure that editors are aware of this? https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Language_Bindings/Components.utils.unload already says this ( "You should not unload modules that are part of the application (anything under resource://gre/ or resource:/// or resource://app/) as these may be in use by other extensions and the application. Only unload modules you include as part of your extension. ") but apparently people aren't reading it there. :-\

https://dxr.mozilla.org/addons/search?q=unload+console.jsm&redirect=false

only points to slyzoom and a bunch of things that aren't on AMO (at least 2 of those hits are the test pilot add-on).

Comment 9

[:Gijs (he/him)]

And indeed, Peter's profile has the universal add-on.

Comment 10

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #9)
> And indeed, Peter's profile has the universal add-on.

*universal search, sigh.

Comment 11

[:Gijs (he/him)]

Filed bug 1288397 to take away the footgun from the XPCOM/XPConnect API layer. Not sure how hard that'll be and/or if it gets traction though...

Comment 12

[Jorge Villalobos [:jorgev] (he/him)]

A written guideline wouldn't be very effective because it's a hard thing to spot. I don't think it will be in reviewers' minds unless we have a validator warning for it. Andreas, would it be possible to flag this?

Comment 13

[Andreas Wagner [:TheOne] [use NI]]

I'm not sure this can be done easily. The amo-validator is a beast and as soon as you want to add a rule that is not a regular expression (which causes a lot of false positives), it's getting very complicated or too hard to actually do.

Is there a list of module namespaces defined by Firefox? (or are the three URIs mentioned on that MDN page all there is?) Maybe we could at least check for them? I think trying to find out which namespaces the add-on defines is next to impossible, using the current codebase.

Comment 14

[:Gijs (he/him)]

(In reply to Andreas Wagner [:TheOne] from comment #13)
> or are the three URIs mentioned on that MDN page all there is?

They're the main ones, yes. IIRC pdfjs and maybe loop/pocket have their own things, but they seem less likely to be abused. Mind you, Cu.import() on those is fine - it's the unloading that is the problem.

Comment 15

[Andreas Wagner [:TheOne] [use NI]]

Thanks!

https://dxr.mozilla.org/addons/search?q=regexp%3A%5C.unload%5C(%5B%27%22%5Dresource%3A%2F%2F(gre%7Capp)%3F%2F&redirect=false

does not output that much. How common is this problem? I am usually all up for validator warnings, if only implementing them wasn't such a big pain.

Comment 16

[:Gijs (he/him)]

(In reply to Andreas Wagner [:TheOne] from comment #15)
> Thanks!
> 
> https://dxr.mozilla.org/addons/search?q=regexp%3A%5C.
> unload%5C(%5B%27%22%5Dresource%3A%2F%2F(gre%7Capp)%3F%2F&redirect=false
> 
> does not output that much. How common is this problem? I am usually all up
> for validator warnings, if only implementing them wasn't such a big pain.

It's not that common, but unloading these files has hard-to-debug and severe functional consequences ranging from "just" form submit on websites being mysteriously broken to core functionality going AWOL. E.g. I'm fairly sure that if you unloaded PrivateBrowsingUtils.jsm you'd probably break pretty much every tab/window management UI endpoint and a great deal besides. So hopefully you'd notice in that case. But apparently in some cases it's hard enough to notice that it actually gets shipped in add-ons, and that'd be quite good to avoid. As I said in bug 1288397, even people in MoCo itself are getting it wrong, so...

Comment 17

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2016-07-22 at 3.27.55 PM.png

It happened again :(
Rendered every form submission lame. 

This time I was quicker to open the Browser Console. 
Note the interesting "unloadFromWindow" from universal-search.

Comment 18

[:Gijs (he/him)]

(In reply to Peter Bengtsson [:peterbe] from comment #17)
> Created attachment 8773909 [details]
> Screen Shot 2016-07-22 at 3.27.55 PM.png
> 
> It happened again :(
> Rendered every form submission lame. 
> 
> This time I was quicker to open the Browser Console. 
> Note the interesting "unloadFromWindow" from universal-search.

This is a problem with the universal-search (test pilot) add-on. They've already fixed it locally, they just need to release a new version with the fix. Until that point my best advice is to restart Firefox.

Marking this WFM because there's not much Firefox can do about this.