Make sure to mention extension messages incompatibilities between Firefox and Google Chrome in the "Chrome incompatibilities" docpage on MDN
Categories
(WebExtensions :: General, task, P3)
Tracking
(firefox82 affected, firefox83 affected, firefox84 affected)
People
(Reporter: ben, Unassigned)
Details
(Keywords: dev-doc-needed)
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:82.0) Gecko/20100101 Firefox/82.0
Steps to reproduce:
In my Background Script, I'm using Vuex as a data store. Vuex wraps
basic Javascript objects with reactive getters and setters, which exposes the problem reported in this ticket.
When a plain old Javascript object is defined in the Vuex Store's state
, it is automatically transformed to wrap defined properties with a getter and setter.
If my Content Script receives an object from the Vuex state (via a response to sendMessage), the properties are defined on Google Chrome, but they are undefined in Firefox.
I have a simple sample repository that reproduces the problem on Github: https://github.com/blimmer/firefox-sendmessage-response-example . The README explains how to easily reproduce the problem locally.
Actual results:
When an object is requested from Vuex state by the Content Script via browser.runtime.sendMessage
, the properties are defined in Google Chrome but undefined in Firefox (see attached screenshot).
I can work around this issue by using Object.assign
to copy the properties into a new Object before returning to the Content Script.
Originally, I thought this might have something to do with Firefox's XRay Vision feature. However, because I can work around the issue using Object.assign
, I don't think that's the case.
Expected results:
I'm not sure which browser is "doing it right" according to the spec. I reviewed the MDN docs and it wasn't obvious what the spec allows in response to a sendMessage
call from a content script. Either way, I wanted to bring it up as an inconsistency.
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Hello,
I’ve reproduced the issue based on the instructions from https://github.com/blimmer/firefox-sendmessage-response-example on the latest Nightly (84.0a1/20201020145547), Beta (83.0b2/20201020173725) and Release (82.0/20201014125134) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS. I’ve also tested the Google Chrome (86.0.4240.75) for comparison.
On Firefox, as stated in the report (and shown in the screenshots), the response proprieties are not defined, as opposed to Chrome.
I’ve also attempted to check whether the issue is a regression. As such I have run a regression range spanning 2018-01-01 until the present day and all tested builds were affected. So the issue does not look to be a regression.
Comment 2•4 years ago
|
||
(In reply to Ben Limmer from comment #0)
Actual results:
When an object is requested from Vuex state by the Content Script via
browser.runtime.sendMessage
, the properties are defined in Google Chrome but undefined in Firefox (see attached screenshot).I can work around this issue by using
Object.assign
to copy the properties into a new Object before returning to the Content Script.Originally, I thought this might have something to do with Firefox's XRay Vision feature. However, because I can work around the issue using
Object.assign
, I don't think that's the case.
Yeah, this is not an issue related to the xray vision, that is only going to affect access to objects that are coming from a different principal (e.g. in the context of an extension that does happen for data exchanged between a website and an extension content script).
This issue is actually related to the fact that on Chrome the extension messaging is internally JSON serializing and deserializing the message, whereas in Firefox we do use structured cloning.
Your workaround (e.g. using Object.assign
, or other similar ways, to turn the object with the vuex reactive getters and setters into a plain object) looks the right one.
Expected results:
I'm not sure which browser is "doing it right" according to the spec. I reviewed the MDN docs and it wasn't obvious what the spec allows in response to a
sendMessage
call from a content script. Either way, I wanted to bring it up as an inconsistency.
I checked out "Chrome incompatibilities" docpage on MDN (and also checked the API reference pages for runtime.sendMessage) and it looks that at the moment we are not yet explicitly mentioning this incompatibility, adding some notes about this in the "Chrome incompatibilities" docpage would be good.
I'm adding a dev-doc-needed flag on this issue and I'm going to change this issue to point it out that it is meant to be about updating the docs.
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 3•4 years ago
|
||
As mentioned above in this thread, using JSON
serialize / deserialize is more accurate than the Object.assign
behavior from my original comment. Instead, if you're implementing a workaround from this report, do something like this:
const result = //something
return JSON.parse(JSON.serialize(result));
Comment 4•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Description
•