Open Bug 1469304 Opened 6 years ago Updated 2 years ago

Extension error of content script doesn't appear in DevTool console

Categories

(DevTools :: Console, defect, P2)

60 Branch
defect

Tracking

(Not tracked)

People

(Reporter: fuweichin, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180605201706

Steps to reproduce:

To write a compatible web extension across browsers, so I have content_script content.js which contains the following code
```
var browser=window.browser||window.chrome;
try{
  console.log(browser);
}catch(e){
  console.log(e);//ReferenceError: browser is not defined
}
```

Firefox ESR 60.0.2 (64 bit)
Windows Pro 10.0.17134 (64 bit)


Actual results:

`console.log(browser);` causes a ReferenceError which says "browser is not defined". while there is no error in Chrome or Edge.


Expected results:

I cannot understand why there would be a ReferenceError "browser is not defined", and most important, the error doesn't appear in DevTool console, I need to use try-catch to find it out.

P.S. After creating two cross-browser extensions, I found that compared to Chrome and Edge, Firefox provides more compatible Web Extension APIs but it takes me more time to debug due to shortage of debugging tools.
I tested this on Windows 10 with esr 60.0.2 and it is reproducible. I can see "ReferenceError: browser is not defined" using the steps in comment 0.


Test env't
-----------
Version 	60.0.1
Build ID 	20180516032417
Update Channel 	esr
User Agent 	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Status: UNCONFIRMED → NEW
Component: Untriaged → Console
Ever confirmed: true
Product: Firefox → DevTools
(In reply to Fuwei Chin from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0)
> Gecko/20100101 Firefox/60.0
> Build ID: 20180605201706
> 
> Steps to reproduce:
> 
> To write a compatible web extension across browsers, so I have
> content_script content.js which contains the following code
> ```
> var browser=window.browser||window.chrome;
> try{
>   console.log(browser);
> }catch(e){
>   console.log(e);//ReferenceError: browser is not defined
> }
> ```

About the reason for the ReferenceError, it is likely to be because of Bug 1208775:
on Firefox, in a content script context `this !== window`
Thanks for reporting this issue Fuwei,
I'm not very familiar with extensions, would you have a link to a simple extension that triggers the error ?
Also, the error might be only available in the Browser console https://developer.mozilla.org/en-US/docs/Tools/Browser_Console
Priority: -- → P3
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #3)
> Thanks for reporting this issue Fuwei,
> I'm not very familiar with extensions, would you have a link to a simple
> extension that triggers the error ?
> Also, the error might be only available in the Browser console
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Console

The extension contains two files:

1. manifest.json
```
{
  "name": "SimpleExtension",
  "version": "0.1.0",
  "manifest_version": 2,
  "description": "Simple extension to demonstrate a bug of Firefox",
  "permissions": [ "storage" ],
  "browser_action": {
    "default_title": "SimpleExtension"
  },
  "content_scripts": [
    {
      "matches": [ "file://*/*", "http://*/*", "https://*/*" ],
      "js": [ "content.js" ]
    }
  ]
}
```

2. content.js
```
var browser=window.browser||window.chrome;
try{
  console.log(browser);
}catch(e){
  console.error(e);//ReferenceError: browser is not defined
}
```

if I don't use try-catch, the error did occurr but won't appear in DevTools console
Thanks Fuwei, it's very helpful.
I can indeed reproduce, without try/catch, the error does not appear anywhere.
I tested with the following script in content.js so we don't get distracted by browser: 

```js
  console.log("before");
  a.dfgfdg;
  console.log("after");
```


I scanned the packets sent via RDP and found nothing related to this error.
However, I was able to see the error in my terminal: 

> JavaScript error: moz-extension://69c85595-3d3d-7149-aa33-e425faef7ec3/content.js, line 4: ReferenceError: a is not defined

I don't know extensions enough to find why this error isn't reported as it should. Luca, would you have an idea about this ?
Flags: needinfo?(lgreco)
Priority: P3 → P2
(In reply to Nicolas Chevobbe [:nchevobbe] from comment #5)
> ...
> I can indeed reproduce, without try/catch, the error does not appear
> anywhere.
> I tested with the following script in content.js so we don't get distracted
> by browser: 
> 
> ```js
>   console.log("before");
>   a.dfgfdg;
>   console.log("after");
> ```
> 
> 
> I scanned the packets sent via RDP and found nothing related to this error.
> However, I was able to see the error in my terminal: 
> 
> > JavaScript error: moz-extension://69c85595-3d3d-7149-aa33-e425faef7ec3/content.js, line 4: ReferenceError: a is not defined
> 
> I don't know extensions enough to find why this error isn't reported as it
> should. Luca, would you have an idea about this ?

Hi Nicolas,
These errors are not been sent to the devtools client in the RDP packets because their are being actually filtered out on the server side by the webconsole actor (or better "by the listeners that the webconsole actor subscribe on the server side of the RDP connection").

The version with the try/catch uses the console API object, which the content script sandbox inherits from the webpage window that it is hooked on, and so the console messages that are emitted by this console object are actually marked with the inner window ID of that webpage.

This inner / window IDs are then used by the webconsole RDP actor to filter out the console messages that are relevant for
the current target window:

- filtering on the console API messages: https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/devtools/server/actors/webconsole/listeners.js#288-294 

The errors are also filtered using a similar strategy:

- filtering on the errors message: https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/devtools/server/actors/webconsole/listeners.js#70-89 
- filtering on the cached errors messages: https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/devtools/server/actors/webconsole/listeners.js#147-163

And so, the reason for the missing errors is that "the errors raised from a WebExtensions content script sandbox are not currently associated to its related window" and, like described above, the webconsole actor is filtering out these errors because are currently detected as non-relevant.

Sometimes ago I filed Bug 1410932 about that and looked into tracking down the different code paths that could make these errors coming from a content script sandbox:

- errors raised when the content script source (or url) is being evaluated
- errors raised from a DOM event listener / callback subscribed by a content script
- uncaught rejections related to a content script

I expect that most of those patches can't be applied to a recent mozilla-central anymore, but they can still be helpful to get a picture of the different scenarios that should be covered to make the errors raised from a content script to be explicitly associated to window IDs of their target webpage, and then visible as expected in the webconsole opened on the related target webpage.
Flags: needinfo?(lgreco)
Thanks a lot for the detailed write-up Luca ! I remember that issue now.
Let's block this bug on it and see if we can prioritize it soon-ish
Depends on: 1410932

Any update on this?

Any update on this?
A cleaner reproduce

{
    "name": "~ test",
    "version": "1.0.0",
    "manifest_version": 2,
    "permissions": ["<all_urls>"],
    "content_scripts": [{ "matches": ["<all_urls>"], "js": ["./x.js"] }]
}

x.js

throw new Error()
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.