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)
Tracking
(Not tracked)
NEW
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.
Comment 1•6 years ago
|
||
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
Comment 2•6 years ago
|
||
(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`
Comment 3•6 years ago
|
||
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
Updated•6 years ago
|
Priority: -- → P3
Reporter | ||
Comment 4•6 years ago
|
||
(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
Comment 5•6 years ago
|
||
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)
Updated•6 years ago
|
Priority: P3 → P2
Comment 6•6 years ago
|
||
(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)
Comment 7•6 years ago
|
||
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
Comment 8•5 years ago
|
||
Any update on this?
https://github.com/facebook/react/issues/16605 affected by this.
Comment 10•4 years ago
|
||
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()
Updated•2 years ago
|
Blocks: webextension-debugging
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•