-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
runtime.sendMessage/onMessage #58
Comments
I think the two errors always happen but they are not reported when using |
(tested with Chrome 61 and latest polyfill version (0.1.2)) If I use
I think that we should catch this specific error and ignore it (treat it as no response). |
I got this error from the content script:
I only got the extension working with |
For me, it does not matter which combination of If I use If I use I am using Chrome 61 and polyfill version 0.2.0. |
i can confirm that #57 fixes the issues mentioned above in a sense that |
@ahmadassaf @Rob--W I was already using what is now named 0.2.0 when I witnessed and opened the issue, as I built the polyfill from |
It appears Chrome 61 might have been updated since I opened the issue. Without changing my code, here is what I now get in the content script console when I use Looks similar to @FayneAldan and @jowa0720, but slightly different. Might be because of slightly different versions of Chrome. My version right now is 61.0.3163.100 on Windows 10 x64. Anyway, this error does not stop the message from going through. However, the message does not get through when I use |
@hgwood i have just noticed something in my
Since i want my extension to work mainly in Chrome and FF, i added this check for FF and then assigning the message listener accordingly. I do no use |
Just want to chime in and say that I'm currently hitting this issue. I'm going to see if browser specific workaround posted by ahmadassaf will work for me. |
My code
The popup does: await browser.tabs.executeScript(tabId, {file: '/browser-polyfill.min.js'})
await browser.tabs.executeScript(tabId, {file: '/content-script.js'})
await browser.tabs.sendMessage(tab.id, {action: 'getHeadings'}) and function messageReceived (message) {
return Promise.resolve(...)
}
browser.runtime.onMessage.addListener(messageReceived) I suggest using 0.1.2 for now. |
I confirm that 0.1.2 also works for me. |
My workaround was to create my own polyfill, using https://github.com/tfoxy/chrome-promise as a start, and filling in the non-callback ones with a simple re-bind from browser to chrome. |
The fix for this issues (#64) has been included in the 0.2.1 release (https://github.com/mozilla/webextension-polyfill/releases/tag/0.2.1) and published on npm. |
Originally, the polyfill created a Proxy with the original API object as the target. This was changed to `Object.create(chrome)` because not doing so would prevent the `browser.devtools` API from working because the devtools API object is assigned as a read-only & non-configurable property (mozilla#57). However, that action itself caused a new bug: Whenever an API object is dereferenced via the `browser` namespace, the original API is no longer available in the `chrome` namespace, and trying to access the API through `chrome` returns `undefined` plus the "Previous API instantiation failed" warning (mozilla#58). This is because Chrome lazily initializes fields in the `chrome` API, but on the object from which the property is accessed, while the polyfill accessed the property through an object with the prototype set to `chrome` instead of directly via chrome. To fix that, `Object.create(chrome)` was replaced with `Object.assign({}, chrome)`. This fixes both of the previous issues because 1) It is still a new object. 2) All lazily initialized fields are explicitly initialized. This fix created a new issue: In Chrome some APIs cannot be used even though they are visible in the API (e.g. `chrome.clipboard`), so calling `Object.assign({}, chrome)` causes an error to be printed to the console (mozilla#70). To solve this, I use `Object.create(chrome)` again as a proxy target, but dereference the API via the original target (`chrome`) to not regress on mozilla#58. Besides fixing the bug, this also reduces the performance impact of the API because all API fields are lazily initialized again, instead of upon start-up. This fixes mozilla#70.
Originally, the polyfill created a Proxy with the original API object as the target. This was changed to `Object.create(chrome)` because not doing so would prevent the `browser.devtools` API from working because the devtools API object is assigned as a read-only & non-configurable property (mozilla#57). However, that action itself caused a new bug: Whenever an API object is dereferenced via the `browser` namespace, the original API is no longer available in the `chrome` namespace, and trying to access the API through `chrome` returns `undefined` plus the "Previous API instantiation failed" warning (mozilla#58). This is because Chrome lazily initializes fields in the `chrome` API, but on the object from which the property is accessed, while the polyfill accessed the property through an object with the prototype set to `chrome` instead of directly via chrome. To fix that, `Object.create(chrome)` was replaced with `Object.assign({}, chrome)`. This fixes both of the previous issues because 1) It is still a new object. 2) All lazily initialized fields are explicitly initialized. This fix created a new issue: In Chrome some APIs cannot be used even though they are visible in the API (e.g. `chrome.clipboard`), so calling `Object.assign({}, chrome)` causes an error to be printed to the console (mozilla#70). To solve this, I use `Object.create(chrome)` again as a proxy target, but dereference the API via the original target (`chrome`) to not regress on mozilla#58. Besides fixing the bug, this also reduces the performance impact of the API because all API fields are lazily initialized again, instead of upon start-up. This fixes mozilla#70.
Originally, the polyfill created a Proxy with the original API object as the target. This was changed to `Object.create(chrome)` because not doing so would prevent the `browser.devtools` API from working because the devtools API object is assigned as a read-only & non-configurable property (#57). However, that action itself caused a new bug: Whenever an API object is dereferenced via the `browser` namespace, the original API is no longer available in the `chrome` namespace, and trying to access the API through `chrome` returns `undefined` plus the "Previous API instantiation failed" warning (#58). This is because Chrome lazily initializes fields in the `chrome` API, but on the object from which the property is accessed, while the polyfill accessed the property through an object with the prototype set to `chrome` instead of directly via chrome. To fix that, `Object.create(chrome)` was replaced with `Object.assign({}, chrome)`. This fixes both of the previous issues because 1) It is still a new object. 2) All lazily initialized fields are explicitly initialized. This fix created a new issue: In Chrome some APIs cannot be used even though they are visible in the API (e.g. `chrome.clipboard`), so calling `Object.assign({}, chrome)` causes an error to be printed to the console (#70). To solve this, I use `Object.create(chrome)` again as a proxy target, but dereference the API via the original target (`chrome`) to not regress on #58. Besides fixing the bug, this also reduces the performance impact of the API because all API fields are lazily initialized again, instead of upon start-up. This fixes #70.
Hello
I'm running into problems when trying to use
browser.runtime.sendMessage
andbrowser.runtime.onMessage
with this polyfill on Chrome 61.I have this code that works fine:
If I replace
chrome
withbrowser
in the background script, I get this in its console:and the listener is not run.
Independently, if I replace
chrome
withbrowser
on the content script side, I get this in the console of the page:but the listener is run.
If I replace
chrome
withbrowser
on both sides, then the content script says this instead:and the background script message remains unchanged.
I'm new to writing browser extensions so I'm not sure if this might be a bug in the polyfill or if not using the API quite right.
The text was updated successfully, but these errors were encountered: